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-21 12:19:02 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!feed.news.nacamar.de!news.belwue.de!news.uni-stuttgart.de!news.enyo.de!not-for-mail From: Florian Weimer Newsgroups: comp.lang.ada Subject: Re: ISO/IEC 14519 - Ada POSIX binding Date: Sat, 21 Jun 2003 21:19:01 +0200 Message-ID: <87r85nqlwa.fsf@deneb.enyo.de> References: <3EF2F6B8.3030706@noplace.com> <3EF338C5.2010005@cogeco.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: albireo.enyo.de 1056223141 3066 212.9.189.171 (21 Jun 2003 19:19:01 GMT) X-Complaints-To: Cancel-Lock: sha1:F1JSrjJxGvvLtglxoAc0qEubfUE= Xref: archiver1.google.com comp.lang.ada:39534 Date: 2003-06-21T21:19:01+02:00 List-Id: 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).