Bug#227386: libc6-dev: ENOTSUP==EOPNOTSUPP, which violates SUSv3
severity 227386 important
clone 227386 -1
reassign -1 linux-2.6
retitle -1 linux-2.6: ENOTSUP and EOPNOTSUPP should be different
thanks, control, and have a nice day
[Copied and pasted from the bug log, because I don't have the original.]
> At Mon, 12 Jan 2004 22:21:39 +0000,
> Brian M. Carlson <sandals@crustytoothpaste.ath.cx> wrote:
> > ENOTSUP is the same as EOPNOTSUPP.
>
> Because linux kernel does not distinct both, moreover they don't
> return ENOTSUP.
I have cloned this to the Linux kernel. I really don't care which package
fixes it, as long as it is fixed, and soon.
My complaint is not that Linux doesn't return one or the other code, it's
that they are the same, which breaks code that checks for both, as well as
violating SUSv3.
> > SUSv3 requires these two values to be
> > distinct, even though no function uses both of them. The obvious
> > solution is for glibc to remap EOPNOTSUPP to the new ENOTSUP code when
> > the error code should be ENOTSUP. The SUSv3 functions that use ENOTSUP
> > are:
>
> Well SuSv3 said that:
>
> 7685 The <errno.h> header shall provide a declaration for errno and give positive values for the
> 7686 following symbolic constants. Their values shall be unique except as noted below. |
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Please note that this is not the case in GNU/Linux. Last time I checked (yesterday),
only EAGAIN and EWOULDBLOCK are allowed (but not required) to be the
same.
> However from checking below functions, they merely returns ENOTSUP.
> Only pthread_attr_setscope and timer_create return ENOTSUP. Linux
> kernel provides almost all function or just returns ENOSYS. Is this
> modification really needed? I believe it's really trivial.
I don't understand your first sentence WRT your second sentence.
The list I gave that you quoted only included functions that
return ENOTSUP.
I agree that the problem is trivial, but it's still a bug, and it
bites me frequently. I am a little disappointed that a bug that
is probably quite trivial to fix has been open for over two
years.
Anyway, my problem is that the fact that these two errors are
the same is causing my code to break very badly. I have a
library that contains its own error codes that will be negative
if casted to an int. Additionally, I want to support the use
of the standard errno.h error codes. To make my life easier,
I am using a script to generate a list of valid error codes:
the POSIX ones, as well as mine. The code generated by the
script uses a switch statement to check whether a code is
valid. But because two case statements cannot have the same
value, I get compiler errors. I have logic to check for
EAGAIN and EWOULDBLOCK, and only use one if both are the same;
I'd prefer not to have to do this for other pairs.
So, here are some solutions, as I see them (in order of my
preference):
0. glibc fixes the error codes so that they are different
(I prefer this because GNU/kFreeBSD has the same problem,
unfortunately).
1. Linux fixes the error codes so that they are different.
2. I use a series of if statements to work around the bug.
If gcc warns that one of the statements will never be reached,
I punt and use option 3 instead, after wasting an hour.
3. I work around the bug by adding logic to check if they
are the same and print a big fat warning telling people
that GNU/Linux is buggered and encouraging people to use
an OS that cares about POSIX compatibility.
4. I tell people that GNU/Linux is not supported out of the
box.
Right now, it looks like if either 0 or 1 don't happen by
18:00 UTC on Monday, that I will do option 2 (falling back
to option 3 as stated).
Reply to: