[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#227386: libc6-dev: ENOTSUP==EOPNOTSUPP, which violates SUSv3



On Mon, 2006-02-20 at 17:37 +0100, Gabor Gombas wrote:
> That seems overly complex. You should most certainly know the range of
> your own error codes, so something like the below looks much simpler (no
> script needed, no dependance on the value of standard error codes):

The problem with that is my error codes are not contiguous; the top byte
of each is 1xxxxxx (the one is so that they will be negative) where the
x's are the subsystem ID.  I would still have to use a case statement,
at least for my own error codes.

> 	if (error_code >= MY_ERROR_MIN && error_code <= MY_ERROR_MAX)
> 	{
> 		/* handle your own error codes here */
> 	}
> 	else
> 	{
> 		errno = 0;
> 		(void *)strerror(error_code);

Not thread safe.  Also, this code does not check that it is a *POSIX*
error code.  If you check the Linux sources, you can see that there are
many error codes (mostly for NFS) that are not standard, and therefore
are invalid for my program.

> After a quick check at least Darwin 6.8 and FreeBSD 5.1 also uses the
> same value for ENOTSUP and EOPNOTSUPP, so if you want to be portable,
> you can not assume that these values are distinct.

I don't know if those claim to support the standard.  If they do, I can
most certainly assume that, just as if __STDC__ is defined that I am
using standard C.

Again, if this will not be fixed, then glibc should not claim to support
the standard until and unless the standard changes.  I have a patch
forthcoming which mitigates the damage and allows people that really
want standards compliance to indicate so.

Attachment: signature.asc
Description: This is a digitally signed message part


Reply to: