Bug#227386: libc6-dev: ENOTSUP==EOPNOTSUPP, which violates SUSv3
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.
> 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. |
7747 [ENOTSUP] Not supported.
7750 [EOPNOTSUPP] Operation not supported on socket.
1039 [ENOTSUP]
1040 Not supported. The implementation does not support this feature of the Realtime Option
1041 Group.
1049 [EOPNOTSUPP]
1050 Operation not supported on socket. The type of socket (address family or protocol) does not
1051 support the requested operation.
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.
> clock_nanosleep
> mmap
> mprotect
> pthread_attr_getinheritsched
> pthread_attr_getschedparam
> pthread_attr_getschedpolicy
> pthread_attr_getscope
> pthread_attr_setinheritsched
> pthread_attr_setschedparam
> pthread_attr_setschedpolicy
> pthread_attr_setscope
> pthread_getschedparam
> pthread_mutexattr_getprioceiling
> pthread_mutexattr_getprotocol
> pthread_mutexattr_setprioceiling
> pthread_mutexattr_setprotocol
> pthread_setschedparam
> pthread_setschedprio
> shm_open
> sigaction
> timer_create
Regards,
-- gotom
Reply to: