* ISO/IEC 14519 - Ada POSIX binding @ 2003-06-19 21:43 Mark Lorenzen 2003-06-19 21:29 ` tmoran ` (2 more replies) 0 siblings, 3 replies; 46+ messages in thread From: Mark Lorenzen @ 2003-06-19 21:43 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: ISO/IEC 14519 - Ada POSIX binding 2003-06-19 21:43 ISO/IEC 14519 - Ada POSIX binding Mark Lorenzen @ 2003-06-19 21:29 ` tmoran 2003-06-28 23:48 ` Richard Riehle 2003-06-20 11:57 ` Marin David Condic 2003-06-21 19:09 ` Florian Weimer 2 siblings, 1 reply; 46+ messages in thread From: tmoran @ 2003-06-19 21:29 UTC (permalink / raw) >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. ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: ISO/IEC 14519 - Ada POSIX binding 2003-06-19 21:29 ` tmoran @ 2003-06-28 23:48 ` Richard Riehle 0 siblings, 0 replies; 46+ messages in thread From: Richard Riehle @ 2003-06-28 23:48 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: ISO/IEC 14519 - Ada POSIX binding 2003-06-19 21:43 ISO/IEC 14519 - Ada POSIX binding Mark Lorenzen 2003-06-19 21:29 ` tmoran @ 2003-06-20 11:57 ` Marin David Condic 2003-06-20 14:08 ` Ludovic Brenta 2003-06-21 19:09 ` Florian Weimer 2 siblings, 1 reply; 46+ messages in thread From: Marin David Condic @ 2003-06-20 11:57 UTC (permalink / raw) 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 ====================================================================== ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: ISO/IEC 14519 - Ada POSIX binding 2003-06-20 11:57 ` Marin David Condic @ 2003-06-20 14:08 ` Ludovic Brenta 2003-06-20 16:39 ` Warren W. Gay VE3WWG 2003-06-21 12:11 ` Marin David Condic 0 siblings, 2 replies; 46+ messages in thread From: Ludovic Brenta @ 2003-06-20 14:08 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: ISO/IEC 14519 - Ada POSIX binding 2003-06-20 14:08 ` Ludovic Brenta @ 2003-06-20 16:39 ` Warren W. Gay VE3WWG 2003-06-20 18:33 ` tmoran ` (3 more replies) 2003-06-21 12:11 ` Marin David Condic 1 sibling, 4 replies; 46+ messages in thread From: Warren W. Gay VE3WWG @ 2003-06-20 16:39 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: ISO/IEC 14519 - Ada POSIX binding 2003-06-20 16:39 ` Warren W. Gay VE3WWG @ 2003-06-20 18:33 ` tmoran 2003-06-20 19:09 ` Warren W. Gay VE3WWG 2003-06-21 19:14 ` Florian Weimer 2003-06-20 19:24 ` Georg Bauhaus ` (2 subsequent siblings) 3 siblings, 2 replies; 46+ messages in thread From: tmoran @ 2003-06-20 18:33 UTC (permalink / raw) >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. ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: ISO/IEC 14519 - Ada POSIX binding 2003-06-20 18:33 ` tmoran @ 2003-06-20 19:09 ` Warren W. Gay VE3WWG 2003-06-21 19:14 ` Florian Weimer 1 sibling, 0 replies; 46+ messages in thread From: Warren W. Gay VE3WWG @ 2003-06-20 19:09 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: ISO/IEC 14519 - Ada POSIX binding 2003-06-20 18:33 ` tmoran 2003-06-20 19:09 ` Warren W. Gay VE3WWG @ 2003-06-21 19:14 ` Florian Weimer 2003-06-21 19:42 ` tmoran 1 sibling, 1 reply; 46+ messages in thread From: Florian Weimer @ 2003-06-21 19:14 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: ISO/IEC 14519 - Ada POSIX binding 2003-06-21 19:14 ` Florian Weimer @ 2003-06-21 19:42 ` tmoran 2003-06-21 21:04 ` Robert I. Eachus 2003-06-29 15:05 ` Florian Weimer 0 siblings, 2 replies; 46+ messages in thread From: tmoran @ 2003-06-21 19:42 UTC (permalink / raw) >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". ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: ISO/IEC 14519 - Ada POSIX binding 2003-06-21 19:42 ` tmoran @ 2003-06-21 21:04 ` Robert I. Eachus 2003-06-29 15:05 ` Florian Weimer 1 sibling, 0 replies; 46+ messages in thread From: Robert I. Eachus @ 2003-06-21 21:04 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: ISO/IEC 14519 - Ada POSIX binding 2003-06-21 19:42 ` tmoran 2003-06-21 21:04 ` Robert I. Eachus @ 2003-06-29 15:05 ` Florian Weimer 1 sibling, 0 replies; 46+ messages in thread From: Florian Weimer @ 2003-06-29 15:05 UTC (permalink / raw) 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* ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: ISO/IEC 14519 - Ada POSIX binding 2003-06-20 16:39 ` Warren W. Gay VE3WWG 2003-06-20 18:33 ` tmoran @ 2003-06-20 19:24 ` Georg Bauhaus 2003-06-20 20:49 ` Warren W. Gay VE3WWG 2003-06-20 20:49 ` Wesley Groleau 2003-06-21 13:01 ` Pascal Obry 3 siblings, 1 reply; 46+ messages in thread From: Georg Bauhaus @ 2003-06-20 19:24 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: ISO/IEC 14519 - Ada POSIX binding 2003-06-20 19:24 ` Georg Bauhaus @ 2003-06-20 20:49 ` Warren W. Gay VE3WWG 0 siblings, 0 replies; 46+ messages in thread From: Warren W. Gay VE3WWG @ 2003-06-20 20:49 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: ISO/IEC 14519 - Ada POSIX binding 2003-06-20 16:39 ` Warren W. Gay VE3WWG 2003-06-20 18:33 ` tmoran 2003-06-20 19:24 ` Georg Bauhaus @ 2003-06-20 20:49 ` Wesley Groleau 2003-06-20 23:05 ` Mark Lorenzen 2003-06-21 1:49 ` David Emery 2003-06-21 13:01 ` Pascal Obry 3 siblings, 2 replies; 46+ messages in thread From: Wesley Groleau @ 2003-06-20 20:49 UTC (permalink / raw) > 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. ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: ISO/IEC 14519 - Ada POSIX binding 2003-06-20 20:49 ` Wesley Groleau @ 2003-06-20 23:05 ` Mark Lorenzen 2003-06-21 1:49 ` David Emery 1 sibling, 0 replies; 46+ messages in thread From: Mark Lorenzen @ 2003-06-20 23:05 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: ISO/IEC 14519 - Ada POSIX binding 2003-06-20 20:49 ` Wesley Groleau 2003-06-20 23:05 ` Mark Lorenzen @ 2003-06-21 1:49 ` David Emery 2003-06-21 19:19 ` Florian Weimer 1 sibling, 1 reply; 46+ messages in thread From: David Emery @ 2003-06-21 1:49 UTC (permalink / raw) 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) ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: ISO/IEC 14519 - Ada POSIX binding 2003-06-21 1:49 ` David Emery @ 2003-06-21 19:19 ` Florian Weimer 2003-06-21 21:47 ` David Emery 0 siblings, 1 reply; 46+ messages in thread From: Florian Weimer @ 2003-06-21 19:19 UTC (permalink / raw) 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). ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: ISO/IEC 14519 - Ada POSIX binding 2003-06-21 19:19 ` Florian Weimer @ 2003-06-21 21:47 ` David Emery 2003-06-21 22:22 ` Larry Kilgallen 2003-06-23 16:13 ` Warren W. Gay VE3WWG 0 siblings, 2 replies; 46+ messages in thread From: David Emery @ 2003-06-21 21:47 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: ISO/IEC 14519 - Ada POSIX binding 2003-06-21 21:47 ` David Emery @ 2003-06-21 22:22 ` Larry Kilgallen 2003-06-23 16:13 ` Warren W. Gay VE3WWG 1 sibling, 0 replies; 46+ messages in thread From: Larry Kilgallen @ 2003-06-21 22:22 UTC (permalink / raw) 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 ? ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: ISO/IEC 14519 - Ada POSIX binding 2003-06-21 21:47 ` David Emery 2003-06-21 22:22 ` Larry Kilgallen @ 2003-06-23 16:13 ` Warren W. Gay VE3WWG 2003-06-23 22:41 ` Berend de Boer 1 sibling, 1 reply; 46+ messages in thread From: Warren W. Gay VE3WWG @ 2003-06-23 16:13 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: ISO/IEC 14519 - Ada POSIX binding 2003-06-23 16:13 ` Warren W. Gay VE3WWG @ 2003-06-23 22:41 ` Berend de Boer 2003-06-24 9:52 ` Lutz Donnerhacke 0 siblings, 1 reply; 46+ messages in thread From: Berend de Boer @ 2003-06-23 22:41 UTC (permalink / raw) >>>>> "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. (-: ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: ISO/IEC 14519 - Ada POSIX binding 2003-06-23 22:41 ` Berend de Boer @ 2003-06-24 9:52 ` Lutz Donnerhacke 2003-06-24 20:43 ` Berend de Boer 0 siblings, 1 reply; 46+ messages in thread From: Lutz Donnerhacke @ 2003-06-24 9:52 UTC (permalink / raw) * 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 ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: ISO/IEC 14519 - Ada POSIX binding 2003-06-24 9:52 ` Lutz Donnerhacke @ 2003-06-24 20:43 ` Berend de Boer 2003-06-25 9:02 ` Pascal Obry 2003-06-25 9:46 ` Lutz Donnerhacke 0 siblings, 2 replies; 46+ messages in thread From: Berend de Boer @ 2003-06-24 20:43 UTC (permalink / raw) >>>>> "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. (-: ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: ISO/IEC 14519 - Ada POSIX binding 2003-06-24 20:43 ` Berend de Boer @ 2003-06-25 9:02 ` Pascal Obry 2003-06-25 9:46 ` Lutz Donnerhacke 1 sibling, 0 replies; 46+ messages in thread From: Pascal Obry @ 2003-06-25 9:02 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: ISO/IEC 14519 - Ada POSIX binding 2003-06-24 20:43 ` Berend de Boer 2003-06-25 9:02 ` Pascal Obry @ 2003-06-25 9:46 ` Lutz Donnerhacke 2003-06-25 21:19 ` Berend de Boer 1 sibling, 1 reply; 46+ messages in thread From: Lutz Donnerhacke @ 2003-06-25 9:46 UTC (permalink / raw) * 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. ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: ISO/IEC 14519 - Ada POSIX binding 2003-06-25 9:46 ` Lutz Donnerhacke @ 2003-06-25 21:19 ` Berend de Boer 0 siblings, 0 replies; 46+ messages in thread From: Berend de Boer @ 2003-06-25 21:19 UTC (permalink / raw) >>>>> "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. (-: ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: ISO/IEC 14519 - Ada POSIX binding 2003-06-20 16:39 ` Warren W. Gay VE3WWG ` (2 preceding siblings ...) 2003-06-20 20:49 ` Wesley Groleau @ 2003-06-21 13:01 ` Pascal Obry 3 siblings, 0 replies; 46+ messages in thread From: Pascal Obry @ 2003-06-21 13:01 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: ISO/IEC 14519 - Ada POSIX binding 2003-06-20 14:08 ` Ludovic Brenta 2003-06-20 16:39 ` Warren W. Gay VE3WWG @ 2003-06-21 12:11 ` Marin David Condic 2003-06-21 12:44 ` Ludovic Brenta 1 sibling, 1 reply; 46+ messages in thread From: Marin David Condic @ 2003-06-21 12:11 UTC (permalink / raw) 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 ====================================================================== ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: ISO/IEC 14519 - Ada POSIX binding 2003-06-21 12:11 ` Marin David Condic @ 2003-06-21 12:44 ` Ludovic Brenta 2003-06-21 13:03 ` Larry Kilgallen 2003-06-23 16:36 ` Warren W. Gay VE3WWG 0 siblings, 2 replies; 46+ messages in thread From: Ludovic Brenta @ 2003-06-21 12:44 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: ISO/IEC 14519 - Ada POSIX binding 2003-06-21 12:44 ` Ludovic Brenta @ 2003-06-21 13:03 ` Larry Kilgallen 2003-06-21 22:28 ` Ludovic Brenta 2003-06-23 16:36 ` Warren W. Gay VE3WWG 1 sibling, 1 reply; 46+ messages in thread From: Larry Kilgallen @ 2003-06-21 13:03 UTC (permalink / raw) 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 ? ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: ISO/IEC 14519 - Ada POSIX binding 2003-06-21 13:03 ` Larry Kilgallen @ 2003-06-21 22:28 ` Ludovic Brenta 2003-06-22 3:45 ` Larry Kilgallen 0 siblings, 1 reply; 46+ messages in thread From: Ludovic Brenta @ 2003-06-21 22:28 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: ISO/IEC 14519 - Ada POSIX binding 2003-06-21 22:28 ` Ludovic Brenta @ 2003-06-22 3:45 ` Larry Kilgallen 2003-06-22 8:47 ` Mark Lorenzen 0 siblings, 1 reply; 46+ messages in thread From: Larry Kilgallen @ 2003-06-22 3:45 UTC (permalink / raw) 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 ? ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: ISO/IEC 14519 - Ada POSIX binding 2003-06-22 3:45 ` Larry Kilgallen @ 2003-06-22 8:47 ` Mark Lorenzen 0 siblings, 0 replies; 46+ messages in thread From: Mark Lorenzen @ 2003-06-22 8:47 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: ISO/IEC 14519 - Ada POSIX binding 2003-06-21 12:44 ` Ludovic Brenta 2003-06-21 13:03 ` Larry Kilgallen @ 2003-06-23 16:36 ` Warren W. Gay VE3WWG 2003-06-24 11:46 ` Marin David Condic 1 sibling, 1 reply; 46+ messages in thread From: Warren W. Gay VE3WWG @ 2003-06-23 16:36 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: ISO/IEC 14519 - Ada POSIX binding 2003-06-23 16:36 ` Warren W. Gay VE3WWG @ 2003-06-24 11:46 ` Marin David Condic 0 siblings, 0 replies; 46+ messages in thread From: Marin David Condic @ 2003-06-24 11:46 UTC (permalink / raw) 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 ====================================================================== ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: ISO/IEC 14519 - Ada POSIX binding 2003-06-19 21:43 ISO/IEC 14519 - Ada POSIX binding Mark Lorenzen 2003-06-19 21:29 ` tmoran 2003-06-20 11:57 ` Marin David Condic @ 2003-06-21 19:09 ` Florian Weimer 2003-06-21 22:38 ` Mark Lorenzen 2 siblings, 1 reply; 46+ messages in thread From: Florian Weimer @ 2003-06-21 19:09 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: ISO/IEC 14519 - Ada POSIX binding 2003-06-21 19:09 ` Florian Weimer @ 2003-06-21 22:38 ` Mark Lorenzen 2003-06-21 22:51 ` Ludovic Brenta ` (2 more replies) 0 siblings, 3 replies; 46+ messages in thread From: Mark Lorenzen @ 2003-06-21 22:38 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: ISO/IEC 14519 - Ada POSIX binding 2003-06-21 22:38 ` Mark Lorenzen @ 2003-06-21 22:51 ` Ludovic Brenta 2003-06-23 16:54 ` Warren W. Gay VE3WWG 2003-06-23 16:46 ` Warren W. Gay VE3WWG 2003-06-29 15:10 ` Florian Weimer 2 siblings, 1 reply; 46+ messages in thread From: Ludovic Brenta @ 2003-06-21 22:51 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: ISO/IEC 14519 - Ada POSIX binding 2003-06-21 22:51 ` Ludovic Brenta @ 2003-06-23 16:54 ` Warren W. Gay VE3WWG 2003-06-24 11:49 ` Marin David Condic 0 siblings, 1 reply; 46+ messages in thread From: Warren W. Gay VE3WWG @ 2003-06-23 16:54 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: ISO/IEC 14519 - Ada POSIX binding 2003-06-23 16:54 ` Warren W. Gay VE3WWG @ 2003-06-24 11:49 ` Marin David Condic 2003-06-24 13:31 ` Warren W. Gay VE3WWG 0 siblings, 1 reply; 46+ messages in thread From: Marin David Condic @ 2003-06-24 11:49 UTC (permalink / raw) 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 ====================================================================== ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: ISO/IEC 14519 - Ada POSIX binding 2003-06-24 11:49 ` Marin David Condic @ 2003-06-24 13:31 ` Warren W. Gay VE3WWG 0 siblings, 0 replies; 46+ messages in thread From: Warren W. Gay VE3WWG @ 2003-06-24 13:31 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: ISO/IEC 14519 - Ada POSIX binding 2003-06-21 22:38 ` Mark Lorenzen 2003-06-21 22:51 ` Ludovic Brenta @ 2003-06-23 16:46 ` Warren W. Gay VE3WWG 2003-06-23 22:43 ` Berend de Boer 2003-06-29 15:10 ` Florian Weimer 2 siblings, 1 reply; 46+ messages in thread From: Warren W. Gay VE3WWG @ 2003-06-23 16:46 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: ISO/IEC 14519 - Ada POSIX binding 2003-06-23 16:46 ` Warren W. Gay VE3WWG @ 2003-06-23 22:43 ` Berend de Boer 0 siblings, 0 replies; 46+ messages in thread From: Berend de Boer @ 2003-06-23 22:43 UTC (permalink / raw) >>>>> "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. (-: ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: ISO/IEC 14519 - Ada POSIX binding 2003-06-21 22:38 ` Mark Lorenzen 2003-06-21 22:51 ` Ludovic Brenta 2003-06-23 16:46 ` Warren W. Gay VE3WWG @ 2003-06-29 15:10 ` Florian Weimer 2003-06-29 20:58 ` David Emery 2 siblings, 1 reply; 46+ messages in thread From: Florian Weimer @ 2003-06-29 15:10 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: ISO/IEC 14519 - Ada POSIX binding 2003-06-29 15:10 ` Florian Weimer @ 2003-06-29 20:58 ` David Emery 0 siblings, 0 replies; 46+ messages in thread From: David Emery @ 2003-06-29 20:58 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 46+ messages in thread
end of thread, other threads:[~2003-06-29 20:58 UTC | newest] Thread overview: 46+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2003-06-19 21:43 ISO/IEC 14519 - Ada POSIX binding Mark Lorenzen 2003-06-19 21:29 ` tmoran 2003-06-28 23:48 ` Richard Riehle 2003-06-20 11:57 ` Marin David Condic 2003-06-20 14:08 ` Ludovic Brenta 2003-06-20 16:39 ` Warren W. Gay VE3WWG 2003-06-20 18:33 ` tmoran 2003-06-20 19:09 ` Warren W. Gay VE3WWG 2003-06-21 19:14 ` Florian Weimer 2003-06-21 19:42 ` tmoran 2003-06-21 21:04 ` Robert I. Eachus 2003-06-29 15:05 ` Florian Weimer 2003-06-20 19:24 ` Georg Bauhaus 2003-06-20 20:49 ` Warren W. Gay VE3WWG 2003-06-20 20:49 ` Wesley Groleau 2003-06-20 23:05 ` Mark Lorenzen 2003-06-21 1:49 ` David Emery 2003-06-21 19:19 ` Florian Weimer 2003-06-21 21:47 ` David Emery 2003-06-21 22:22 ` Larry Kilgallen 2003-06-23 16:13 ` Warren W. Gay VE3WWG 2003-06-23 22:41 ` Berend de Boer 2003-06-24 9:52 ` Lutz Donnerhacke 2003-06-24 20:43 ` Berend de Boer 2003-06-25 9:02 ` Pascal Obry 2003-06-25 9:46 ` Lutz Donnerhacke 2003-06-25 21:19 ` Berend de Boer 2003-06-21 13:01 ` Pascal Obry 2003-06-21 12:11 ` Marin David Condic 2003-06-21 12:44 ` Ludovic Brenta 2003-06-21 13:03 ` Larry Kilgallen 2003-06-21 22:28 ` Ludovic Brenta 2003-06-22 3:45 ` Larry Kilgallen 2003-06-22 8:47 ` Mark Lorenzen 2003-06-23 16:36 ` Warren W. Gay VE3WWG 2003-06-24 11:46 ` Marin David Condic 2003-06-21 19:09 ` Florian Weimer 2003-06-21 22:38 ` Mark Lorenzen 2003-06-21 22:51 ` Ludovic Brenta 2003-06-23 16:54 ` Warren W. Gay VE3WWG 2003-06-24 11:49 ` Marin David Condic 2003-06-24 13:31 ` Warren W. Gay VE3WWG 2003-06-23 16:46 ` Warren W. Gay VE3WWG 2003-06-23 22:43 ` Berend de Boer 2003-06-29 15:10 ` Florian Weimer 2003-06-29 20:58 ` David Emery
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox