Re: ISO/IEC 14519 - Ada POSIX binding

["Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca>]

Ludovic Brenta wrote:
> Marin David Condic <nobody@noplace.com> writes:
...
>>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

Note the "uniX". Some things in the POSIX standard are difficult
to implement on other platforms (Windows quickly comes to mind).

> 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.  

There are a number of situations where this is difficult, yeah
verily, maybe impossible. Its been a while since I've looked at
this but can W2k/XP support fork(2), select(2) and or poll(2)
APIs for example?

>>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.

But there _are_ problems WRT Ada. The first that comes to mind is
the whole error handling approach. POSIX likes the idea of an errno
value with errno codes. The Ada approach often uses exceptions, and
perhaps supplementary information APIs, which differ decidedly from
the POSIX interface.

Additionally, POSIX defines very C-ish like routines like read(2)
and write(2), where in Ada a streams approach would likely be
more natural.  So implementing read(2) or msgrecv(2) in an Ada
package doesn't make much sense in a strongly typed language like
Ada.

>>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.

As listed above there are reasons why POSIX cannot be used directly
with Ada.

Sure, it may be used underneath the hood, much like Ada.Text_IO
is. But you won't find fopen(3), fread(3) etc. routines used in
Ada over Ada.Text_IO (normally) for the same reasons. The POSIX
API is not overly suitable to a type safe language like Ada. POSIX
works well with C/C++ where you can override type safety by default.

> 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.

Ah, but have you tried to use this package on Windows?  It isn't
even complete under UNIX (for example, you can't yet use UNIX
sockets with Florist).

-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg