Re: [boost] [system] Status update

From: Oliver.Kowalke_at_[hidden]
Date: 2007-05-21 02:15:25

> > I believe that will cause problems because EAGAIN could 
> have the same 
> > value as EWOULDBLOCK (for instance LINUX).
> 
> Can you come up with an actual use case where than would 
> cause problems? 
> (I'm not saying such a use case doesn't exist; merely that I 
> can't think of one offhand.)

If the elements in the error enumeration of the proposal get the
corresponding POSIX errno assigned than it 
EWOULDBLOCK and EAGAIN would cause troubles.

On some systems (for instance FreeBSD) EWOULDBLOCK is returned from
none-blocking 'accept' if the request would block. On HP/UX it could
return EAGAIN.

>> Maybe some
> >>> posix errors are missing (I'm not sure).
> >> Please do an independent check. I have missed something. The POSIX 
> >> folks suggested adding a couple of new errors POSIX is in 
> process of 
> >> adding, by the way.
> > 
>  > ENXIO
> 
> That one actually is present in the working paper.

OK - maybe I overlooked that.
 
> > ESTALE
> > EMULTIHOP
> > EDQUOT
> 
> Those three are reserved by POSIX, but are not given any 
> definition and so were deliberately omitted. Do you have a 
> counter-argument in favor of including them? If so, how 
> should their enums be defined?

I found it on http://www.die.net/doc/linux/man/man3/errno.3.html.

> > EAI_ADDRFAMILY
> > EAI_AGAIN
> > EAI_BADFLAGS
> > EAI_FAIL
> > EAI_FAMILY
> > EAI_MEMORY
> > EAI_NODATA
> > EAI_NONAME
> > EAI_SERVICE
> > EAI_SOCKTYPE
> > EAI_SYSTEM
> 
> None of those are defined by
> http://www.opengroup.org/onlinepubs/009695399/basedefs/errno.h
> .html#tag_13_10
> which I'm assuming is the gold standard for the POSIX errno.h 
> errors that are the basis for the portable error codes. So 
> even though the errors you mention above are defined 
> elsewhere in the POSIX standard, they seem to me to be in a 
> different error_category.

The getaddrinfo() function is defined in IEEE Std 1003.1g-2000
(``POSIX.1''), and documented in ``Basic Socket Interface Extensions for
IPv6'' (RFC2553).

Regards, Oliver