From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,2d2df3e9ad18fa63 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-06-23 09:28:54 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!cyclone.bc.net!snoopy.risq.qc.ca!news.uunet.ca!nf3.bellglobal.com!nf1.bellglobal.com!nf2.bellglobal.com!news20.bellglobal.com.POSTED!not-for-mail Message-ID: <3EF7273A.8060704@cogeco.ca> From: "Warren W. Gay VE3WWG" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: ISO/IEC 14519 - Ada POSIX binding References: <3EF2F6B8.3030706@noplace.com> <3EF338C5.2010005@cogeco.ca> <87r85nqlwa.fsf@deneb.enyo.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Date: Mon, 23 Jun 2003 12:13:46 -0400 NNTP-Posting-Host: 198.96.223.163 X-Complaints-To: abuse@sympatico.ca X-Trace: news20.bellglobal.com 1056384827 198.96.223.163 (Mon, 23 Jun 2003 12:13:47 EDT) NNTP-Posting-Date: Mon, 23 Jun 2003 12:13:47 EDT Organization: Bell Sympatico Xref: archiver1.google.com comp.lang.ada:39610 Date: 2003-06-23T12:13:46-04:00 List-Id: David Emery wrote: > Florian Weimer wrote: >> David Emery 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