Bug#227386: libc6-dev: ENOTSUP==EOPNOTSUPP, which violates SUSv3
On Fri, Feb 24, 2006 at 08:46:23AM +0000, Brian M. Carlson wrote:
> Neither side is willing to "lose" and give in all the way. I tried a
> compromise. Apparently, that didn't work, so let me try another one:
> glibc could no longer claim compliance with SUSv3/POSIX 1003.1-2001 or
> SUSv2. Then there will be no bug, and we can all be happy.
Well, it would certainly make sense to document the known deviations
from the various standards. Keeping the list up-to-date may be
problematic however, so I think this still should be coordinated with
upstream.
> * libfoo is compiled against glibc 2.3.6.
> * bar is compiled against libfoo and glibc 2.3.6.
> * A new version of bar comes out, and is compiled against glibc 2.3.7
> (which no longer has the bug in question, let's say).
> * Now, several things could happen:
> + bar passes the error code it gets from some libc function to libfoo,
> and libfoo tries to handle it, libfoo errors out and bar no longer
> works.
IMHO this is acceptable as this should not be common and can be handled
by using versioned dependencies on libfoo.
> + bar passes the error code it gets from some libc function to libfoo,
> which then tries to log the error by using strerror. This will cause
> silent breakage.
IMHO the version of strerror() need not be incremented in this case, so
both bar and libfoo will use the same strerror() version.
> This solution will avoid the vast majority of problems, but it isn't
> perfect. I am getting the impression that the others here want a
> "perfect" solution, and other than changing SONAMEs (which no one wants
> to do), it can't be done, AFAICT. If someone can find a solution which
> works in all cases, please let me know.
I don't think a perfect solution is needed. You only need to keep the
benefits/expected breakage ratio acceptable, and since fixing the errno
values provides only a really small benefit, the expected breakage
should be quite low.
> I found the change in question, where Mr. Drepper claims that Linus
> rejected his patch to create an ENOTSUP, and so he defined ENOTSUP to
> EOPNOTSUPP. But I cannot find the patch that Linus rejected.
Nor did I. It is well known that Ulrich Drepper and Linus Torvalds do
not get along well. In this case I think Ulrich was wrong, but he did
not want to acknowledge it. Sure, it is convinient if the kernel returns
the same error code as glibc wants, but nothing stops glibc from
remapping the error code if this is not the case. After all, the
standards define the behaviour of the _library_ functions, not the
kernel<->glibc interface.
> I also
> find his claim in the glibc bug I opened that it is part of the ABI
> unconvincing, especially now that I know it was he who made the change,
> and therefore part of the ABI.
>
> Also, I have no idea why the two errors were made the same, when item
> number 2 in the PROJECTS file is:
>
> [ 2] Test compliance with standards. If you have access to recent
> standards (IEEE, ISO, ANSI, X/Open, ...) and/or test suites you
> could do some checks as the goal is to be compliant with all
> standards if they do not contradict each other.
>
> This has apparently been in that file since it was checked in, 9 years
> and 8 months ago.
Yep, Ulrich Drepper seems to be a man hard to deal with. But it is true
that ENOTSUP == EOPNOTSUPP is part of the _current_ ABI, and changing
that would be very unwise if it is not accepted upstream.
> No, I can be sure they have separate values now, because glibc defines
> _POSIX_VERSION to 200112L. That indicates *complete* and *total*
> support of the base portions of POSIX 1003.1-2001. Such portions
> include the two error code in question.
No, that at most indicates _intent_ to support the standard. The
standard says that compliant systems should set that symbol to that
value; it does not (and can not) say that non-compliant systems should
not set it. "Complete" and "total" support would mean being officially
certified, but that's not the case.
And that's exactly the reason why real-world applications use solutions
like autoconf instead of depending on feature macros. It's not just
Linux, commercial vendors also have their fair share of standard
non-compliance bugs from time to time.
Gabor
--
---------------------------------------------------------
MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
---------------------------------------------------------
Reply to: