Re: ISO/IEC 14519 - Ada POSIX binding

Re: ISO/IEC 14519 - Ada POSIX binding

[tmoran]

>There has lately been some discussions on c.l.a about defining a
>socket package for use with Ada 200Y - either as a part of the
>standard or as a de-facto standard socket package.
>...
>I think it would be better to require that vendors support the ISO/IEC
>14519 instead of trying to define all sorts of packages that do not
  Is there a description of the ISO/IEC 14519 socket binding available
somewhere on the web?  (I live in Silicon Valley, where the technical
bookstore went out of business.)
  One problem with "a" standard package is that different people have
different needs.  That's most obvious with a sort package where different
algorithms have different characteristics, but it also applies to the
convenience/flexibility tradeoff in something like sockets.

ISO/IEC 14519 - Ada POSIX binding

[Mark Lorenzen]

There has lately been some discussions on c.l.a about defining a
socket package for use with Ada 200Y - either as a part of the
standard or as a de-facto standard socket package.

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.

I think it would be better to require that vendors support the ISO/IEC
14519 instead of trying to define all sorts of packages that do not
have the inter-operability and common data types that the ISO/IEC
14519 packages have.

What is your opinion?

- Mark

Re: ISO/IEC 14519 - Ada POSIX binding

[Marin David Condic]

I am not familiar with that standard, so I don't know about any specific 
problems. I would comment on some general problems:

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.

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.

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?

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.

MDC



Mark Lorenzen wrote:
> There has lately been some discussions on c.l.a about defining a
> socket package for use with Ada 200Y - either as a part of the
> standard or as a de-facto standard socket package.
> 
> 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.
> 
> I think it would be better to require that vendors support the ISO/IEC
> 14519 instead of trying to define all sorts of packages that do not
> have the inter-operability and common data types that the ISO/IEC
> 14519 packages have.
> 
> What is your opinion?
> 
> - Mark


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jast.mil/

Send Replies To: m c o n d i c @ a c m . o r g

     "In general the art of government consists in taking as
     much money as possible from one class of citizens to give
     to the other."

         --  Voltaire
======================================================================

Re: ISO/IEC 14519 - Ada POSIX binding

[Ludovic Brenta]

Marin David Condic <nobody@noplace.com> 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.

Re: ISO/IEC 14519 - Ada POSIX binding

[Warren W. Gay VE3WWG]

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

Re: ISO/IEC 14519 - Ada POSIX binding

[tmoran]

>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
  I have the paper version of IEEE 1003.5-1992 which specifically has a
discussion of why that Ada binding to POSIX uses exception handling
instead of errno.  ISO/IEC 14519 appears to be a successor, covering more
ground (eg sockets).  The Ada binding is thick in the sense of using
exceptions, strong typing, generics, tasking, etc, but it's still pretty
"close to the hardware".  It also was designed pre-Ada95.  In designing
CLAW, we studied the 1003.5-1992 book, but in many cases went for a higher
abstraction level.  For instance, claw sockets need merely Open, Write,
Close (Close is optional, actually, thanks to Finalization) with lots of
stuff, like the multiple states a socket can be in, happening "under the
hood".  There are projects that need the detailed level of control, and
there are projects that will be implemented faster with the simplified
interface.  I don't think a one-size-fits-all standard socket binding
would be adequate.

Re: ISO/IEC 14519 - Ada POSIX binding

[Warren W. Gay VE3WWG]

tmoran@acm.org wrote:
>>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
> 
>   I have the paper version of IEEE 1003.5-1992 which specifically has a
> discussion of why that Ada binding to POSIX uses exception handling
> instead of errno.  ISO/IEC 14519 appears to be a successor, covering more
> ground (eg sockets).  The Ada binding is thick in the sense of using
> exceptions, strong typing, generics, tasking, etc, but it's still pretty
> "close to the hardware".  It also was designed pre-Ada95.  In designing
> CLAW, we studied the 1003.5-1992 book, but in many cases went for a higher
> abstraction level.  For instance, claw sockets need merely Open, Write,
> Close (Close is optional, actually, thanks to Finalization) with lots of
> stuff, like the multiple states a socket can be in, happening "under the
> hood".  There are projects that need the detailed level of control, and
> there are projects that will be implemented faster with the simplified
> interface.  I don't think a one-size-fits-all standard socket binding
> would be adequate.

The point of a standardized package is not necessarily to have
"one-size-fits-all", though that might be one goal, if it were
possible. Ada.Text_IO is certainly not "one-size-fits-all" for
text I/O, but yet, it works sufficiently well for a large majority
of the cases required for applications.  I think many people would
be happy to achieve something similar for network programming.

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

Re: ISO/IEC 14519 - Ada POSIX binding

[Georg Bauhaus]

Warren W. Gay VE3WWG <ve3wwg@cogeco.ca> wrote:
: Note the "uniX". Some things in the POSIX standard are difficult
: to implement on other platforms (Windows quickly comes to mind).

Some more on this:
http://www.research.att.com/sw/tools/uwin/


Georg

Re: ISO/IEC 14519 - Ada POSIX binding

[Wesley Groleau]

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

The POSIX binding I looked at had a single exception,
POSIX_Error and then you were supposed to examine the
errno variable.  Proctalgia, but it's the price you pay
for interfacing to such a primitive system.  Rather than
"roll-your-own" completely, I'd say use POSIX as a thin
binding and provide a thick binding to wrap it in.

Re: ISO/IEC 14519 - Ada POSIX binding

[Warren W. Gay VE3WWG]

Georg Bauhaus wrote:
> Warren W. Gay VE3WWG <ve3wwg@cogeco.ca> wrote:
> : Note the "uniX". Some things in the POSIX standard are difficult
> : to implement on other platforms (Windows quickly comes to mind).
> 
> Some more on this:
> http://www.research.att.com/sw/tools/uwin/
> 
> Georg

I didn't look too closely at this, but it reminds me of um,
CYGWIN  8-)

My point, as you know however, is that Windows needs help in
working in POSIX terms.

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

Re: ISO/IEC 14519 - Ada POSIX binding

[Mark Lorenzen]

Wesley Groleau <wesgroleau@despammed.com> writes:

> The POSIX binding I looked at had a single exception,
> POSIX_Error and then you were supposed to examine the
> errno variable.  Proctalgia, but it's the price you pay
> for interfacing to such a primitive system.  Rather than
> "roll-your-own" completely, I'd say use POSIX as a thin
> binding and provide a thick binding to wrap it in.

Yes! The POSIX binding is a (not so)simple binding to a low-level
interface and is therefore also pretty low-level. But it has a huge
advantage, namely that it is POSIX (read PORTABLE) - it is even
implemented for some RT OSes.

I would appreciate a high-level socket or general communication
package, but I think that it is important that the package is based on
the POSIX interface as the interface has a lot of other useful stuff
than just sockets. Imagine that we want to use asynchronous I/O on a
socket - POSIX support that. But async I/O often uses POSIX real-time
signals for event signalling and again it is provided by the POSIX
interface.

When using sockets for real applications, we often need to drag a
whole toolsbox into use f.x. select() or poll(), fcntl(), ioctl() and
so on.

The Ada POSIX Interface is modular, just as the C counterpart, so an
implementation need not implement the whole standard (message queues,
async I/O, co-existence with C threads, RT signals and so on...).

- Mark

Re: ISO/IEC 14519 - Ada POSIX binding

[David Emery]

Wesley Groleau wrote:
...
> The POSIX binding I looked at had a single exception,
> POSIX_Error and then you were supposed to examine the
> errno variable.  Proctalgia, but it's the price you pay
> for interfacing to such a primitive system.  Rather than
> "roll-your-own" completely, I'd say use POSIX as a thin
> binding and provide a thick binding to wrap it in.

If you read the rationale (one of the best parts of the document,
IMHO), you'll see that the primary consideration for this decision
is the fact that the set of errors for any given POSIX system call
is NOT fixed.  POSIX defines a minimum set of error conditions,
implementations may add additional errors (and most have, particularly
as network-based computing has expanded.) Any error handling technique
must accomodate extension.  In general, extension considerations drove
much of the POSIX/Ada design, and with almost 15 years of hindsight,
I think we got the balance between rigid specification and support for
vendor and subsequent standard extensions just about right.

And, as someone else pointed out earlier, the original POSIX/Ada
binding work was done in Ada83.  The standard came out about the same
time as Ada95, and there was a lot of cross-fertilization, so that
we looked at Ada95-like solutions that could be expressed in Ada83.

One specific influence FROM the POSIX/Ada effort was the notion of
Library-level renames, so that we could construct the whole POSIX/Ada95
namespace from library-level renames of the POSIX/Ada83 packages.

			dave (tech editor, original IEEE 1003.5)

Re: ISO/IEC 14519 - Ada POSIX binding

[Marin David Condic]

Ludovic Brenta wrote:
> 
> 
> 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.
>  
I think yuou missed my point. If "Standard X" cites "Standard Y" and 
there is any change to "Standard Y", then "Standard X" has a problem of 
being potentially out of date. It doesn't matter how long "Standard Y" 
has been around - it is a separate standard subject to its own updates, 
enhancements, etc. It would be better for "Standard X" to specify its 
needs in such a way that "Standard Y" might be one method of solving 
them, but not necessarily the only method.




> 
> 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:
> 
Yes, I know what POSIX is. I also know that not every operating system 
on the planet is POSIX-compliant. I also know that there are machines 
with no OS - presumably a sockets package would be an optional thing for 
implementations that didn't require it. I am not against POSIX - I just 
think that if Ada is going to have some kind of sockets package, it 
ought to abstract itself one layer away at least so that POSIX is not 
the only possible answer.


> 
> 
> On the contrary, as I said, POSIX _is_ an abstract interface, and
> implementations have some freedom in how they implement it.
>  
It is an "abstract interface" for a UNIX-like implementation. There are 
OS's besides UNIX and possibly in the next ten years or so that an Ada 
standard would have to live, there may be a bunch more non-UNIX 
operating systems out there. I have no objection to POSIX or UNIX - just 
suggesting that an Ada standard would do well to not dictate either 
POSIX or UNIX as the only possible answer.


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

I am aware of FLORIST. You'd have a problem getting FLORIST adopted as 
the Ada standard - primarily because it is vendor specific and GPL 
licensed. Other vendors will want an answer that does not put GNAT/ACT 
in the driver's seat. (Although this might be a moot issue. One has to 
wonder how many of the other Ada vendors have a vigorous interest in 
future Ada standards. Or are many of them looking at it as a cash-cow to 
be milked for whatever they can get and then move on to more profitable 
markets?)

MDC
-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jast.mil/

Send Replies To: m c o n d i c @ a c m . o r g

     "In general the art of government consists in taking as
     much money as possible from one class of citizens to give
     to the other."

         --  Voltaire
======================================================================

Re: ISO/IEC 14519 - Ada POSIX binding

[Ludovic Brenta]

Marin David Condic writes:

> Ludovic Brenta wrote:
> > 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.
>
> I think you missed my point. If "Standard X" cites "Standard Y" and
> there is any change to "Standard Y", then "Standard X" has a problem
> of being potentially out of date. It doesn't matter how long
> "Standard Y" has been around - it is a separate standard subject to
> its own updates, enhancements, etc. It would be better for "Standard
> X" to specify its needs in such a way that "Standard Y" might be one
> method of solving them, but not necessarily the only method.
 
No, I didn't miss your point.  What I was trying to say is, why should
we need Standard X (Ada sockets) in the first place, if Standard Y
(POSIX.5) already exists?  Especially if Standard Y is an official,
vendor-neutral, portable ISO standard?  But you've answered that
question below.
 
> > 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:
> >
> Yes, I know what POSIX is. I also know that not every operating
> system on the planet is POSIX-compliant. I also know that there are
> machines with no OS - presumably a sockets package would be an
> optional thing for implementations that didn't require it. I am not
> against POSIX - I just think that if Ada is going to have some kind
> of sockets package, it ought to abstract itself one layer away at
> least so that POSIX is not the only possible answer.
>
> > On the contrary, as I said, POSIX _is_ an abstract interface, and
> > implementations have some freedom in how they implement it.
> >
> It is an "abstract interface" for a UNIX-like implementation. There
> are OS's besides UNIX and possibly in the next ten years or so that
> an Ada standard would have to live, there may be a bunch more
> non-UNIX operating systems out there. I have no objection to POSIX
> or UNIX - just suggesting that an Ada standard would do well to not
> dictate either POSIX or UNIX as the only possible answer.

Maybe you have a point here ("all problems can be solved with an
additional level of indirection", I think was the quote).  It probably
depends on how difficult it would be to implement POSIX.5 sockets on
non-POSIX platforms.  Furthermore, I would think that anyone designing
a new OS in the next ten years would want to make it POSIX-compliant,
because it would be too difficult to try an impose an alternative API.
In fact, you've probably noticed that even the MVS and z/OS mainframe
operating systems became POSIX-compliant for just that reason.

So, if anyone on this newsgroup wants to implement a sockets package
in Ada, I'd suggest they make sure the external API is POSIX.5,
whatever their underlying platform is.

> > 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.
> 
> I am aware of FLORIST. You'd have a problem getting FLORIST adopted
> as the Ada standard - primarily because it is vendor specific and
> GPL licensed. Other vendors will want an answer that does not put
> GNAT/ACT in the driver's seat. (Although this might be a moot
> issue. One has to wonder how many of the other Ada vendors have a
> vigorous interest in future Ada standards. Or are many of them
> looking at it as a cash-cow to be milked for whatever they can get
> and then move on to more profitable markets?)

I agree with you entirely.  I wasn't trying to suggest that FLORIST
should becomme the Ada standard.  In fact, FLORIST is an
implementation; the Ada standard would only be an interface (API) and
I still think that this API should be POSIX.5, unless it is
*impossible* (not just difficult) to implement POSIX on some platform.
Ease of implementation was the design goal of C, not Ada.

Currently, I am aware of only one platform that remains non-POSIX, and
that is Windows.  Yet I don't think it would be impossible to write a
POSIX.5 thick binding on top of it (I mean for sockets, not the entire
OS).

-- 
Ludovic Brenta.

Re: ISO/IEC 14519 - Ada POSIX binding

[Pascal Obry]

"Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca> writes:

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

Indeed. I had lot of troubles implementing my Win32POSIX binding.

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

No. There is also some problems with file locking if my memory is right,
and some package just can't* be implemented on Win32.

Pascal.

* Of course it is always possible (see Cygwin for example) but the work will
  be very big. We need to provides a complete POSIX emulation not just a
  binding.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|         http://perso.wanadoo.fr/pascal.obry
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: ISO/IEC 14519 - Ada POSIX binding

[Larry Kilgallen]

In article <m3he6jsiqi.fsf@insalien.org>, Ludovic Brenta <ludovic.brenta@insalien.org> writes:
> Marin David Condic writes:
> 
>> Ludovic Brenta wrote:

>> > On the contrary, as I said, POSIX _is_ an abstract interface, and
>> > implementations have some freedom in how they implement it.
>> >
>> It is an "abstract interface" for a UNIX-like implementation. There
>> are OS's besides UNIX and possibly in the next ten years or so that
>> an Ada standard would have to live, there may be a bunch more
>> non-UNIX operating systems out there. I have no objection to POSIX
>> or UNIX - just suggesting that an Ada standard would do well to not
>> dictate either POSIX or UNIX as the only possible answer.
> 
> Maybe you have a point here ("all problems can be solved with an
> additional level of indirection", I think was the quote).  It probably
> depends on how difficult it would be to implement POSIX.5 sockets on
> non-POSIX platforms.

It is not just a matter of "how difficult" but rather "how illogical".
VMS direct IP access uses the QIO system service which returns status
on every call and after every IO completion.  Layering a C-language
socket structure on top of that introduces the awful "errno" business.
Now should an IP package for Ada go through that C-language layer and
try to undo the "errno" business, or should it call the QIO system service
directly and never get tied up in "errno" at all ?

> Furthermore, I would think that anyone designing
> a new OS in the next ten years would want to make it POSIX-compliant,
> because it would be too difficult to try an impose an alternative API.
> In fact, you've probably noticed that even the MVS and z/OS mainframe
> operating systems became POSIX-compliant for just that reason.

When VMS added Posix-compliant calls it was to allow C programmers
to use it in a fashion to which they were accustomed.  They did
_not_ force all programmers to use those C conventions.  Is the
MVS situation somehow more restrictive ?

Re: ISO/IEC 14519 - Ada POSIX binding

[Florian Weimer]

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.

Re: ISO/IEC 14519 - Ada POSIX binding

[Florian Weimer]

tmoran@acm.org writes:

>   I have the paper version of IEEE 1003.5-1992 which specifically has a
> discussion of why that Ada binding to POSIX uses exception handling
> instead of errno.

Even with Ada 83, they should have used an errno-like variable and a
single exception.  (In Ada 95, you can encode the error code in the
exception message.)  The long exception list results in lots of "when
others =>" clauses silently discarding the exception if you want to
have reliable code which runs on real-world systems.

Re: ISO/IEC 14519 - Ada POSIX binding

[Florian Weimer]

David Emery <demery@cox.net> writes:

> If you read the rationale (one of the best parts of the document,
> IMHO), you'll see that the primary consideration for this decision
> is the fact that the set of errors for any given POSIX system call
> is NOT fixed.  POSIX defines a minimum set of error conditions,
> implementations may add additional errors (and most have, particularly
> as network-based computing has expanded.) Any error handling technique
> must accomodate extension.

And the POSIX.5 mechanism gives us this extensibility?  I don't think
so.

If a POSIX.5 implementation raises an exception not expected by the
application, it won't be able to attribute it to the POSIX subsystem
at all (unless the application jumps through hoops and uses the Ada 95
feature that yields the full expanded name of the exception).

Re: ISO/IEC 14519 - Ada POSIX binding

[tmoran]

>Even with Ada 83, they should have used an errno-like variable and a
>single exception.  (In Ada 95, you can encode the error code in the
>exception message.)  The long exception list results in lots of "when
>others =>" clauses silently discarding the exception if you want to
>have reliable code which runs on real-world systems.
  You are laboring under a misunderstanding.  The Posix binding does not
have a "long exception list" and does not add new exceptions willy-nilly.
As pointed out by Dave Emery, new error codes get added and it would be
absurd to add new exceptions to the "standard" and ask people to add new
exception handlers to their programs.  There is an exception
Posix.Posix_Error to force the program not to ignore problems.  The
program must then get the particular error code and figure out what to do.
I suppose that might translate into "when others =>" in a case statement
in old code, but it would be a bad programmer indeed who decided "There's
an error.  I don't understand it.  I'll just pretend I didn't notice it".

Re: ISO/IEC 14519 - Ada POSIX binding

[Robert I. Eachus]

tmoran@acm.org wrote:

>                                                    There is an exception
> Posix.Posix_Error to force the program not to ignore problems.  The
> program must then get the particular error code and figure out what to do.
> I suppose that might translate into "when others =>" in a case statement
> in old code, but it would be a bad programmer indeed who decided "There's
> an error.  I don't understand it.  I'll just pretend I didn't notice it".

Right, while in C, the normal situation is to ignore the possibility 
that an error code will be returned.  With the Posix binding, an Ada 
exception is raised, so it will find an exeception handler (or terminate 
the task silently).  A programmer can still "ignore" the error, it is 
just a lot more visible if they do.  (when others => null;)

Oh, and I have been asked many times why tasks disappear silently if an 
exception occurs after elaboration.  This is one of those things that 
falls in the third part of the standard.  (What happens if you try to 
shoot yourself in the foot.) You are not required to have an exception 
handler in a task body.  But if there is the remotest chance of an 
exception reaching a handler, the handler should be there. Even if it 
just prints an error message. So why isn't it required?

Because there are several tasking idioms, and the right place for the 
catchall error handler differs. For example:

task body Foo is
   ...;
begin
   loop
     begin
       accept ...;
       ...
     exception
       ...
     end;
   end loop;
end Foo;

Requiring an exception handler outside the loop would be silly.  Not 
having an execption handler inside the loop is also silly.  Another example:

task body Bar is
begin

   declare
   ...
   begin
     accept ...;
     ...
   exception
     ...
   end;

end Bar;

Here the author of the task body decided to encapsulate everything 
inside a declare block, either so that elaborating the declarations 
happens as part of the task, not its creator, or so that execptions 
occuring in the declarations are handled inside the task.  In either 
case requiring another exception handler for the task body as a whole 
would just be a pain.

Re: ISO/IEC 14519 - Ada POSIX binding

[David Emery]

Florian Weimer wrote:

> David Emery <demery@cox.net> writes:
> 
> 
>>If you read the rationale (one of the best parts of the document,
>>IMHO), you'll see that the primary consideration for this decision
>>is the fact that the set of errors for any given POSIX system call
>>is NOT fixed.  POSIX defines a minimum set of error conditions,
>>implementations may add additional errors (and most have, particularly
>>as network-based computing has expanded.) Any error handling technique
>>must accomodate extension.
> 
> 
> And the POSIX.5 mechanism gives us this extensibility?  I don't think
> so.
> 
> If a POSIX.5 implementation raises an exception not expected by the
> application, it won't be able to attribute it to the POSIX subsystem
> at all (unless the application jumps through hoops and uses the Ada 95
> feature that yields the full expanded name of the exception).

An implementation of POSIX.5 that raises any exception other than
POSIX.POSIX_Error (or the predefined exceptions), is NON-CONFORMING
(i.e. "wrong").

The error reporting model is for the POSIX call to raise
POSIX.POSIX_Error.  (Unlike in C...) The application program must
handle this exception somehow, or be terminated.  (In the latter
case, the value of the POSIX process's return code is 42, "Unhandled
Exception."  If this number sounds familiar, you're right.  See the
Rationale for an explanation :-).

Anyway, it's up to the application program to do The Right Thing.
Good practice would be
	CALL_POSIX: begin
		posix_system_call (...);
	exception
		when POSIX.POSIX_Error =>
			case POSIX.Error_Code is
				-- don't quote me on the exact
				-- error code values below
				when POSIX.No_Such_File => ...
				when POSIX.Bad_File_Descriptor => ...
				when others => ...
					-- represents an error the
					-- application cannot handle
		when others => ...
	end CALL_POSIX;

So let's consider the extensibility of this approach.
We add a new error code, "No_Such_Machine".  This could get invoked
by Open() when the pathname starts with 2 slashes, e.g.
	open (file => "//www.adahome.com/updates", ...);
	exception
		when POSIX.POSIX_Error =>
			case POSIX.Error_Code is
			....
If we want, we can add
				when POSIX.No_Such_Machine => ...
to the application, when we know about this new error -AND- what we
should do about it.

A poorly coded application can always do
				when others => null;  -- can't handle
But a better-coded application should do
				when others =>
				    action_for_unknown_problem;

But in ALL CASES, there is a single exception that gets raised,
POSIX.POSIX_Error.

				dave	

Re: ISO/IEC 14519 - Ada POSIX binding

[Larry Kilgallen]

In article <un4Ja.7658$ZE.5855@lakeread05>, David Emery <demery@cox.net> writes:

> The error reporting model is for the POSIX call to raise
> POSIX.POSIX_Error.  (Unlike in C...) The application program must
> handle this exception somehow, or be terminated.  (In the latter
> case, the value of the POSIX process's return code is 42, "Unhandled
> Exception."

What is a "POSIX process" ?

Should not error handling be restricted to the Ada task that encountered
the error ?

Re: ISO/IEC 14519 - Ada POSIX binding

[Ludovic Brenta]

Kilgallen@SpamCop.net (Larry Kilgallen) writes:
> VMS direct IP access uses the QIO system service which returns
> status on every call and after every IO completion.  Layering a
> C-language socket structure on top of that introduces the awful
> "errno" business.  Now should an IP package for Ada go through that
> C-language layer and try to undo the "errno" business, or should it
> call the QIO system service directly and never get tied up in
> "errno" at all ?

The POSIX.5 Ada interface does not have to be implemented on top of
the C interface, so on VMS, a well-written Ada binding would call the
QIO service directly.

As noted elsewhere in this thread, POSIX.5 uses an exception
(Posix.Posix_Error) to report that an error occurred, and an
"errno"-like variable to specify what kind of error occurred.  Thanks
to the exception, a lot of the ugliness goes away, and thanks to the
variable, it is easier to add new error codes to POSIX.5 without
breaking existing apps.
 
> > Furthermore, I would think that anyone designing
> > a new OS in the next ten years would want to make it POSIX-compliant,
> > because it would be too difficult to try an impose an alternative API.
> > In fact, you've probably noticed that even the MVS and z/OS mainframe
> > operating systems became POSIX-compliant for just that reason.
> 
> When VMS added Posix-compliant calls it was to allow C programmers
> to use it in a fashion to which they were accustomed.  They did
> _not_ force all programmers to use those C conventions.  Is the MVS
> situation somehow more restrictive ?

No, the other interfaces to the same operating system services are
still available (note the plural: there are several for different
languages like assembler, PL/I and Rexx).  The addition of a POSIX
interface just makes it easier to port applications to mainframes,
which in today's world appears to be a condition for survival.

-- 
Ludovic Brenta.

Re: ISO/IEC 14519 - Ada POSIX binding

[Mark Lorenzen]

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

Re: ISO/IEC 14519 - Ada POSIX binding

[Ludovic Brenta]

Mark Lorenzen <mark.lorenzen@ofir.dk> writes:

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

Yes.  If the Ada standard library were extended with complete support
for operating system services (or even just sockets) in a non-POSIX
way, it would be almost impossible to persuade people to use Ada at
all in the "general" computing field, even if the library were very
good.  They would object that the learning curve is way too steep,
what with this huge standard library that nobody knows.  If by
contrast you tell them "Ada uses POSIX to talk to the platform so
you'll pick it up in no time", then people will listen and notice how
the exception model makes their Ada programs better than C and C++
programs (there is no C++ API for POSIX, so C++ programs have to use
the crude C interface; Ada programs are blessed with a clean Ada
interface).

And here is another argument to support POSIX.5: Designing a new,
incompatible, Ada interface to OS services would be a huge effort that
would not necessarily yield better results than POSIX.5, but the
results would definitely arrive at least 11 years after POSIX.5.  So,
I think it would be better to take POSIX.5 as a given, and spend
quality time on standardising containers, for example.

To conclude: IMHO, designing a new Ada standard for sockets amounts to
reinventing the wheel.

-- 
Ludovic Brenta.

Re: ISO/IEC 14519 - Ada POSIX binding

[Larry Kilgallen]

In article <m3brwrrrof.fsf@insalien.org>, Ludovic Brenta <ludovic.brenta@insalien.org> writes:

> As noted elsewhere in this thread, POSIX.5 uses an exception
> (Posix.Posix_Error) to report that an error occurred, and an
> "errno"-like variable to specify what kind of error occurred.  Thanks
> to the exception, a lot of the ugliness goes away, and thanks to the
> variable, it is easier to add new error codes to POSIX.5 without
> breaking existing apps.

Is that variable specific to a single task ?

How does one accomplish that without declaring it within the task ?

If it is not specific to a single task, how does one avoid conflict
between tasks on simultaneous errors ?

Re: ISO/IEC 14519 - Ada POSIX binding

[Mark Lorenzen]

Kilgallen@SpamCop.net (Larry Kilgallen) writes:

> In article <m3brwrrrof.fsf@insalien.org>, Ludovic Brenta <ludovic.brenta@insalien.org> writes:
> 
> > As noted elsewhere in this thread, POSIX.5 uses an exception
> > (Posix.Posix_Error) to report that an error occurred, and an
> > "errno"-like variable to specify what kind of error occurred.  Thanks
> > to the exception, a lot of the ugliness goes away, and thanks to the
> > variable, it is easier to add new error codes to POSIX.5 without
> > breaking existing apps.
> 
> Is that variable specific to a single task ?
> 
> How does one accomplish that without declaring it within the task ?
> 
> If it is not specific to a single task, how does one avoid conflict
> between tasks on simultaneous errors ?

It is specific to a single task, just like it is specific to a C thread.

- Mark

Re: ISO/IEC 14519 - Ada POSIX binding

[Warren W. Gay VE3WWG]

David Emery wrote:
> Florian Weimer wrote:
>> David Emery <demery@cox.net> writes:
>>> If you read the rationale (one of the best parts of the document,
>>> IMHO), you'll see that the primary consideration for this decision
>>> is the fact that the set of errors for any given POSIX system call
>>> is NOT fixed.  POSIX defines a minimum set of error conditions,
>>> implementations may add additional errors (and most have, particularly
>>> as network-based computing has expanded.) Any error handling technique
>>> must accomodate extension.
>>
>> And the POSIX.5 mechanism gives us this extensibility?  I don't think
>> so.
>>
>> If a POSIX.5 implementation raises an exception not expected by the
>> application, it won't be able to attribute it to the POSIX subsystem
>> at all (unless the application jumps through hoops and uses the Ada 95
>> feature that yields the full expanded name of the exception).
> 
> An implementation of POSIX.5 that raises any exception other than
> POSIX.POSIX_Error (or the predefined exceptions), is NON-CONFORMING
> (i.e. "wrong").
> 
> The error reporting model is for the POSIX call to raise
> POSIX.POSIX_Error.  (Unlike in C...) The application program must
> handle this exception somehow, or be terminated.  (In the latter
> case, the value of the POSIX process's return code is 42, "Unhandled
> Exception."  If this number sounds familiar, you're right.  See the
> Rationale for an explanation :-).
> 
> Anyway, it's up to the application program to do The Right Thing.
> Good practice would be
>     CALL_POSIX: begin
>         posix_system_call (...);
>     exception
>         when POSIX.POSIX_Error =>
>             case POSIX.Error_Code is
>                 -- don't quote me on the exact
>                 -- error code values below
>                 when POSIX.No_Such_File => ...
>                 when POSIX.Bad_File_Descriptor => ...
>                 when others => ...
>                     -- represents an error the
>                     -- application cannot handle
>         when others => ...
>     end CALL_POSIX;

Does the standard address error codes in any way?

For example, some operations on some platforms return EAGAIN,
while others return EWOULDBLOCK (IIRC, non-blocking I/O does
this for example). Does FLORIST and/or the POSIX standard
take a position on this?

I have always found these issues particularly annoying for
portable code.
-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg

Re: ISO/IEC 14519 - Ada POSIX binding

[Warren W. Gay VE3WWG]

Ludovic Brenta wrote:
> Marin David Condic writes:
>>Ludovic Brenta wrote:
>>>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.
...
>>>POSIX stands for Portable Operating System Interface for uniX.  It
...
>>It is an "abstract interface" for a UNIX-like implementation. There
>>are OS's besides UNIX and possibly in the next ten years or so that
>>an Ada standard would have to live, there may be a bunch more
>>non-UNIX operating systems out there. I have no objection to POSIX
>>or UNIX - just suggesting that an Ada standard would do well to not
>>dictate either POSIX or UNIX as the only possible answer.
> 
> Maybe you have a point here ("all problems can be solved with an
> additional level of indirection", I think was the quote).  It probably
> depends on how difficult it would be to implement POSIX.5 sockets on
> non-POSIX platforms.  Furthermore, I would think that anyone designing
> a new OS in the next ten years would want to make it POSIX-compliant,
> because it would be too difficult to try an impose an alternative API.

That might be good advice, but that has nothing to do with the
present discussion. Embedded systems are not likely to care to
support any concept of POSIX. Also, who knows: maybe there will
be a resurgence of interest in O/S design, and something radically
new and improved will emerge. Why force what can be O/S neutral
to tie itself unnecessarily to one O/S standard?

In fact, I will even go out on a limb here and state that any
Ada.Sockets standard can be completely new in an API sense. It
only has to address the same networking _needs_. The purpose of
the Ada.Sockets package is not for porting C programs to Ada.

New Ada programs can completely disregard prior [API] art,
in terms of how the same functions are achieved. In fact, there
is a strong probability that this will be the case, in order to
preserve the Ada strengths, like Ada streams.

All that is required is that the new standard carefully be
designed to be _portable_ to platforms that it is likely
to be used upon. The rest is mere vendor implementation detail.

> In fact, you've probably noticed that even the MVS and z/OS mainframe
> operating systems became POSIX-compliant for just that reason.
> 
> So, if anyone on this newsgroup wants to implement a sockets package
> in Ada, I'd suggest they make sure the external API is POSIX.5,
> whatever their underlying platform is.

I don't agree, and my reasons are similar to Marin's. Certainly
there is no reason not to use POSIX underneath the hood, where
it makes sense. But I see no need to tie an Ada standard to a
POSIX standard. Nor do I see a need to make an Ada interface
match a C-ish UNIX one (for the record, I am a UNIX fan, saying
this).

>>>P.S. There is already an implementation of the POSIX standard
>>>available at no cost under the GPL.  It is called FLORIST and is
...
> Currently, I am aware of only one platform that remains non-POSIX, and
> that is Windows.  Yet I don't think it would be impossible to write a
> POSIX.5 thick binding on top of it (I mean for sockets, not the entire
> OS).

Given that you will always have O/S's with varieties of O/S APIs, I
see no reason to bind an Ada sockets library on one O/S interface
standard. The goal should be similar to the ones that I presume were
used for Ada.Text_IO : arrive at a portable API that can serve the
majority of needs, for the majority of platforms (I am sure there
are embedded sitatuations where even Text_IO is not implemented).

You'll never standardize an "all singing/dancing"
package, but to come close while remaining portable are the goals
here.

What you seem to imply is that the POSIX API should be the
primary goal instead. This is where I disagree.

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

Re: ISO/IEC 14519 - Ada POSIX binding

[Warren W. Gay VE3WWG]

Mark Lorenzen wrote:
> 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=

Many feel that a standard should be freely available. In this case,
I would agree.  It certainly helps to gain better acceptance.

> And we have a publicly available implementation called 'florist':
> 
> http://libre.act-europe.fr/GNAT/

Ahem, FLORIST is :

  1. only available to GNAT users

  2. portable only to UNIX like systems so far

  3. incomplete (no UNIX/Local socket support yet etc.)

  4. and subject to platform differences (errno EAGAIN vs EWOULDBLOCK
     differences etc.)

> You are correct that POSIX is not perfect, but it is PORTABLE and

Not completely, without planning for the platforms that it is to
compile on. I doubt that FLORIST guarantees uniform errno reporting,
so you end up having to know which platform you are on (or in some
simpler cases, planning for EAGAIN/EWOULDBLOCK as equally likely --
though not all situations are this simple).

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

I am not against POSIX support. I welcome FLORIST improvements (I
use it actively). But to tie another Ada standard package to POSIX
directly is unwise.

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

Well, when you go to run that under Open/Net/FreeBSD, get ready to
make some adjustments. There is a world of difference between Linux
and FreeBSD on some of the APIs. ;-)

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

Re: ISO/IEC 14519 - Ada POSIX binding

[Warren W. Gay VE3WWG]

Ludovic Brenta wrote:
> Mark Lorenzen <mark.lorenzen@ofir.dk> writes:
...
> And here is another argument to support POSIX.5: Designing a new,
> incompatible, 

Whoa on incompatible! Incompatible to what?!?! There is not networking
package on Ada yet. There is no compatibility required!

> Ada interface to OS services would be a huge effort that
> would not necessarily yield better results than POSIX.5, 

No, and no. An Ada.Sockets package is not a complete re-implementation
of networking services any more than Ada.Text_IO must be. In GNAT
for example, the C stdio functions are used underneath the hood. In
the same way, any Ada.Sockets package is not required to re-invent
anything. It is merely a binding to O/S services, except in special
COTS like situations where the vendor may not supply any TCP/IP
service.

> but the
> results would definitely arrive at least 11 years after POSIX.5.  

Bzzzt. Wrong answer. ;-)

Many people have already implemented sockets packages that
are bindings. Ask them how long it took them.

 > So,
> I think it would be better to take POSIX.5 as a given, and spend
> quality time on standardising containers, for example.
> 
> To conclude: IMHO, designing a new Ada standard for sockets amounts to
> reinventing the wheel.

No. Ada.Text_IO is not a re-invention of stdio. For GNAT users, this
merely presents an _interface_. In most cases, this is what
Ada.Sockets will be. An _interface_.

The _only_ exception might be in embedded system situations where
the vendor has chosen to provide TCP/IP support in this way. But
even then, I doubt you would find it happen that way.

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

Re: ISO/IEC 14519 - Ada POSIX binding

[Berend de Boer]

>>>>> "Warren" == Warren W Gay VE3WWG <ve3wwg@cogeco.ca> writes:

    Warren> Does the standard address error codes in any way?

    Warren> For example, some operations on some platforms return
    Warren> EAGAIN, while others return EWOULDBLOCK (IIRC,
    Warren> non-blocking I/O does this for example). Does FLORIST
    Warren> and/or the POSIX standard take a position on this?

I think every current system has:

#define EWOULDBLOCK EGAIN

or something like that (I don't master C).

-- 
Regards,

Berend. (-:

Re: ISO/IEC 14519 - Ada POSIX binding

[Berend de Boer]

>>>>> "Warren" == Warren W Gay VE3WWG <ve3wwg@cogeco.ca> writes:

    Warren> Well, when you go to run that under Open/Net/FreeBSD, get
    Warren> ready to make some adjustments. There is a world of
    Warren> difference between Linux and FreeBSD on some of the
    Warren> APIs. ;-)

Not with regard to the POSIX APIs.

-- 
Regards,

Berend. (-:

Re: ISO/IEC 14519 - Ada POSIX binding

[Lutz Donnerhacke]

* Berend de Boer wrote:
> I think every current system has:
> #define EWOULDBLOCK EGAIN
> or something like that (I don't master C).

No.
work/ada/src/kernel/kernel-linux_i86.ads
[...]
   EAGAIN          : constant error_code :=  11; -- Try again
[...]
   EWOULDBLOCK     : constant error_code :=  41; --  is now EAGAIN
[...]

You never know which code the kernel will return.

But you are right on this:
   ECHILD          : constant error_code :=  10; -- No child processes
-- ECHLD           : constant error_code :=  ECHILD; -- Fucking typos

Re: ISO/IEC 14519 - Ada POSIX binding

[Marin David Condic]

I'd also suggest that if Ada is going to have any sort of sockets 
package, that it ought to be very "Ada-ish" written in "Ada-ese" rather 
than be developed in C using Ada syntax. You definitely want to use Ada 
idioms rather than trying to speak C with an Ada accent. To the extent 
that POSIX caters to C, I'd disregard it - creating a thick binding at 
best to hide things that are C-ish. Things like pointers to null 
terminated arrays of characters and error return codes from functions 
should all be rethought so that they have no existence in an Ada 
standard. Develop the interface so that it has an Ada look-and-feel and 
if it happens to line up nicely with POSIX, fine. But you don't simply 
want to point to POSIX and say "Go use that with Ada syntax"

MDC

Warren W. Gay VE3WWG wrote:
> 
> 
> I don't agree, and my reasons are similar to Marin's. Certainly
> there is no reason not to use POSIX underneath the hood, where
> it makes sense. But I see no need to tie an Ada standard to a
> POSIX standard. Nor do I see a need to make an Ada interface
> match a C-ish UNIX one (for the record, I am a UNIX fan, saying
> this).
> 

-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jast.mil/

Send Replies To: m c o n d i c @ a c m . o r g

     "In general the art of government consists in taking as
     much money as possible from one class of citizens to give
     to the other."

         --  Voltaire
======================================================================

Re: ISO/IEC 14519 - Ada POSIX binding

[Marin David Condic]

So maybe we want to abstract I/O over pipes or sockets in the same way 
that high level languages abstracted I/O to/from files on a disk? I'd 
prefer to see such an abstraction rather than a simple binding to some 
specific OS services that might change over time.

MDC

Warren W. Gay VE3WWG wrote:
> 
> No. Ada.Text_IO is not a re-invention of stdio. For GNAT users, this
> merely presents an _interface_. In most cases, this is what
> Ada.Sockets will be. An _interface_.
> 
> The _only_ exception might be in embedded system situations where
> the vendor has chosen to provide TCP/IP support in this way. But
> even then, I doubt you would find it happen that way.
> 


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jast.mil/

Send Replies To: m c o n d i c @ a c m . o r g

     "In general the art of government consists in taking as
     much money as possible from one class of citizens to give
     to the other."

         --  Voltaire
======================================================================

Re: ISO/IEC 14519 - Ada POSIX binding

[Warren W. Gay VE3WWG]

Marin David Condic wrote:
> So maybe we want to abstract I/O over pipes or sockets in the same way 
> that high level languages abstracted I/O to/from files on a disk? I'd 
> prefer to see such an abstraction rather than a simple binding to some 
> specific OS services that might change over time.
> 
> MDC

Yes. By doing that you give the standard a lifetime independant of other
fads of the day (POSIX being one of them). The "abstraction" also allows
native Ada. Yes.

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

Re: ISO/IEC 14519 - Ada POSIX binding

[Berend de Boer]

>>>>> "Lutz" == Lutz Donnerhacke <lutz@iks-jena.de> writes:

    >> I think every current system has: #define EWOULDBLOCK EGAIN or
    >> something like that (I don't master C).

    Lutz> No.  work/ada/src/kernel/kernel-linux_i86.ads [...]  EAGAIN
    Lutz> : constant error_code := 11; -- Try again [...]  EWOULDBLOCK
    Lutz> : constant error_code := 41; -- is now EAGAIN [...]

    Lutz> You never know which code the kernel will return.

I don't know a thing about Ada, but if you look at the Linux source:

  /usr/include/asm/errno.h

at line 44 on my system you say the equality.

I've no idea why you have the value 41, that's absolutely incorrect.

-- 
Regards,

Berend. (-:

Re: ISO/IEC 14519 - Ada POSIX binding

[Pascal Obry]

Berend de Boer <berend@xsol.com> writes:

> I've no idea why you have the value 41, that's absolutely incorrect.

That's not. The whole point discussed here is that these values are OS
dependent and the behavior is not well defined.

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|         http://perso.wanadoo.fr/pascal.obry
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: ISO/IEC 14519 - Ada POSIX binding

[Lutz Donnerhacke]

* Berend de Boer wrote:
>>>>>> "Lutz" == Lutz Donnerhacke <lutz@iks-jena.de> writes:
>> No.  work/ada/src/kernel/kernel-linux_i86.ads [...]
>> EAGAIN      : constant error_code := 11; -- Try again [...]
>> EWOULDBLOCK : constant error_code := 41; -- is now EAGAIN [...]
>> You never know which code the kernel will return.
>
> I don't know a thing about Ada, but if you look at the Linux source:
>   /usr/include/asm/errno.h
> at line 44 on my system you say the equality.

No. This line says, da� 41 (with was returned by older kernels) does not
have a symbolic name anymore. If you recompile an older program, which
assumes the error code 41, it is leaded to 11 with this kernel.

This does not say anything about returning 41.

Re: ISO/IEC 14519 - Ada POSIX binding

[Berend de Boer]

>>>>> "Lutz" == Lutz Donnerhacke <lutz@iks-jena.de> writes:

    >>> constant error_code := 11; -- Try again [...]  EWOULDBLOCK :
    >>> constant error_code := 41; -- is now EAGAIN [...]  You never
    >>> know which code the kernel will return.

    >>  I don't know a thing about Ada, but if you look at the Linux
    >> source: /usr/include/asm/errno.h at line 44 on my system you
    >> see the equality.

    Lutz> No. This line says, da� 41 (with was returned by older
    Lutz> kernels) does not have a symbolic name anymore. If you
    Lutz> recompile an older program, which assumes the error code 41,
    Lutz> it is leaded to 11 with this kernel.

    Lutz> This does not say anything about returning 41.

The discussion was:

 berend> I think every current system has:
 berend> #define EWOULDBLOCK EGAIN

and yes, that's true.

And I'm not sure what older kernels you're talking about. Pre 1.0
perhaps?

-- 
Regards,

Berend. (-:

Re: ISO/IEC 14519 - Ada POSIX binding

[Richard Riehle]

tmoran@acm.org wrote:

>   Is there a description of the ISO/IEC 14519 socket binding available
> somewhere on the web?  (I live in Silicon Valley, where the technical
> bookstore went out of business.)

For Tom, and others living in Silicon Valley, a well-kept secret is
that Stanford University's Palo Alto Bookstore on University Avenue
still has a great selection technical books.   They allow browsing,
and have some tables set up for serious review reading.  The
selection of Ada books has dropped off sharply since no one but
me seems to buy them anymore.   However, if the demand were to
increase, I have found the buyers quite responsive ans service-oriented.

Richard Riehle

Re: ISO/IEC 14519 - Ada POSIX binding

[Florian Weimer]

tmoran@acm.org writes:

> As pointed out by Dave Emery, new error codes get added and it would be
> absurd to add new exceptions to the "standard" and ask people to add new
> exception handlers to their programs.  There is an exception
> Posix.Posix_Error to force the program not to ignore problems.

Ah, thanks for this explanation.  I think I confused the POSIX.5
binding with a wrapper around the POSIX C interface. *blush*

Re: ISO/IEC 14519 - Ada POSIX binding

[Florian Weimer]

Mark Lorenzen <mark.lorenzen@ofir.dk> writes:

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

For a mere file?  It's not exactly cheap, but you are right, it's much
less than I expected.

When ISO didn't offer PDF downloads, the printed version cost about as
much as the CD version today (CHF 340).

> You are correct that POSIX is not perfect, but it is PORTABLE and
> supported by a lot of interesting platforms.

POSIX is portable, but POSIX applications aren't necessarily so.  At
least the C version of the standard leaves so many loopholes that you
really can't write portable applications on the whiteboard.  I haven't
checked if the Ada version is better in this regard, but FLORIST
doesn't try to hide any discrepancy in the underlying C
implementation, so it doesn't matter that much for us GNAT users.

Re: ISO/IEC 14519 - Ada POSIX binding

[David Emery]

Florian Weimer wrote:
...
> POSIX is portable, but POSIX applications aren't necessarily so.  At
> least the C version of the standard leaves so many loopholes that you
> really can't write portable applications on the whiteboard.  

Despite the lack of rigor in both the C language standard and the
C POSIX binding, many useful programs have been made and ported using
the C API/binding.

For the Ada binding, we tried to plug as many holes as we could, but
without changing the underlying semantics.  In other words, we could
be 'no better' than what the standard required. (In a very few cases,
we did tighten up the semantics, with the understanding that this would
be a potential implementation burden.)

I haven't
> checked if the Ada version is better in this regard, but FLORIST
> doesn't try to hide any discrepancy in the underlying C
> implementation, so it doesn't matter that much for us GNAT users.

To the best of my knowledge, FLORST is not a conforming 1003.5
implementation.

			dave