Re: ISO/IEC 14519 - Ada POSIX binding

["Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca>]

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