Re: ISO/IEC 14519 - Ada POSIX binding

[Mark Lorenzen <mark.lorenzen@ofir.dk>]

Florian Weimer <fw@deneb.enyo.de> writes:

> Mark Lorenzen <mark.lorenzen@ofir.dk> writes:
> 
> > So my big question is therefore: What's wrong with ISO/IEC 14519? It
> > is of course pretty big, but that is a natural consequence of POSIX
> > being big.
> 
> There is no affordable documentation, for a start.  POSIX.5 itself is
> rather expensive.  There is no publicly accessible implementation.  As
> a result, hardly anybody knows how the interface "feels" in practice.
> 
> The rest of POSIX.5 has severe design deficiencies; I think it's
> reasonable to assume that binding to the BSD sockets API is not much
> better.

(Sorry if this is sent twice)

Personally I do not think that 44 CFH (approx. 33 USD) is expensive:

http://www.iso.org/iso/en/CatalogueDetailPage.CatalogueDetail?CSNUMBER=34354&ICS1=35&ICS2=60&ICS3=

And we have a publicly available implementation called 'florist':

http://libre.act-europe.fr/GNAT/

You are correct that POSIX is not perfect, but it is PORTABLE and
supported by a lot of interesting platforms. If we want to persuade
people to using Ada instead of the "usual" languages for anything else
than real-time or embedded systems, then we NEED support for POSIX.

At the company where I work, we have just finished a proposal for a
system that initially must run on Solaris and must then later be
ported to Linux. What is the key here? POSIX! The system consists of
several UNIX processes and makes use of networking sockets, message
queues, real-time signals, memory mapping and memory locking (but not
shared memory). While POSIX may not be perfekt it is what is used in
the "real" world.

We are not all fortunate enough to work on real-time embedded software
projects, where one can afford to write a driver for some special
hardware. There are a lot of applications outside the embedded world
that can benefit from Ada. And in that world strange things like
inter-process communicationa, shared memory and such really matters.

- Mark