Boost logo

Boost :

From: Beman Dawes (bdawes_at_[hidden])
Date: 2007-05-19 22:20:28


Oliver.Kowalke_at_[hidden] wrote:
>
>>> Nice - but I don't know why posix errors are enumerated now.
>> The LWG wanted them to be usable as constants.
>
> 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.)

>>> 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.

> 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?

> 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.

Thanks,

--Beman


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk