From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,2d2df3e9ad18fa63 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-06-20 07:07:08 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newsfeed.icl.net!newsfeed.fjserv.net!skynet.be!skynet.be!louie!tlk!not-for-mail Sender: lbrenta@lbrenta.corp.emc.com Newsgroups: comp.lang.ada Subject: Re: ISO/IEC 14519 - Ada POSIX binding References: <3EF2F6B8.3030706@noplace.com> From: Ludovic Brenta Date: 20 Jun 2003 16:08:33 +0200 Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii NNTP-Posting-Host: 213.190.149.159 X-Trace: 1056118027 reader1.news.skynet.be 1043 fa058819/213.190.149.159:26257 X-Complaints-To: abuse@skynet.be Xref: archiver1.google.com comp.lang.ada:39491 Date: 2003-06-20T16:08:33+02:00 List-Id: Marin David Condic writes: > You might have a variety of problems tying one standard to another. If > the other standard you are referencing is changed, this creates > problems for updating your standard. Are you forced to update your > standard? Do you rely on an out-of-date standard for some potentially > long span of time? Its not insurmountable, but it is an issue. POSIX has been around for a long time now, and yes, people do rely on it. The revision process is long and thorough, much like the Ada standard's. > Also, this POSIX standard may be including a lot of things that might > be difficult to support across a multitude of platforms. Ada was > intended for machines ranging from bare-boards (no OS) up to full-size > machines with lots of different OS's - some of which may not > themselves be POSIX compliant. So you might have issues relating to > the Least Common Denominator syndrome that standards have to deal with. POSIX stands for Portable Operating System Interface for uniX. It defines only the API and its semantics, not how the API is implemented. If there is an underlying POSIX-compliant operating system, then the implementation is trivial. If there is an OS that is not POSIX-compliant, then the implementation is a thick binding to the OS. For bare boards, there is of course a higher implementation cost. But I submit that: - implementing the POSIX sockets from scratch on a bare board would not be more difficult than implementing another kind of sockets - even on bare boards, there probably is a body of available, POSIX-compliant, sockets code, which would alleviate part of the burden. > I don't know at what level this standard is written to, but it may > likely be dealing with lots of lower level things in order to be > applicable across a variety of implementations. If Ada had a sockets > package, I'd like to see it abstract away as much as possible from the > mechanisms used to move the bits. Is that philosophy incompatible with > the standard you cite? On the contrary, as I said, POSIX _is_ an abstract interface, and implementations have some freedom in how they implement it. > It is probably worth a look at the standard to determine its > applicability, but I could imagine some reasons why it might not be > the best answer. I agree, but my a priori opinion is that POSIX would prove suitable; also I don't think it would be a good idea to create a new, incompatible standard. P.S. There is already an implementation of the POSIX standard available at no cost under the GPL. It is called FLORIST and is maintained by ACT. From what I understand, it is currently a thin binding to a POSIX-compliant underlying OS (including sockets), but providing alternative package bodies is probably feasible for all kinds of platforms. See ftp://ftp.cs.nyu.edu/pub/gnat. -- Ludovic Brenta.