At Mon, 12 Jan 2004 22:21:39 +0000, Brian M. Carlson <[EMAIL PROTECTED]> 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