On Thu, 2006-02-23 at 13:24 +0100, Gabor Gombas wrote:
> On Thu, Feb 23, 2006 at 04:30:55AM +0000, Brian M. Carlson wrote:
>
> > > By introducing a new define, you are breaking standard compliance.
> >
> > Well, there is no better way. You want to preserve binary compatibility
> > at the expense of all else. I want to preserve standards compliance at
> > the expense of all else. I am trying to offer a compromise.
>
> You can not "preseve" standards compliance by breaking standards
> compliance, so that's out. What remains is preserving binary compliance,
> and that can be achieved by doing nothing.
What I'm saying is that I'm trying to make everyone happy, or at least
not completely angry. If we went my way, we'd change the numbers, and
screw binary compatibility. If we went your way, we'd screw standards
compatibility and keep the status quo.
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.
> > Actually, no it won't. It will continue to return the "wrong" value
> > (EOPNOTSUPP) that existing code returns. At some point, one might want
> > to fix that with new @GLIBC_2.3.7 symbols, but I'm not going to
> > implement that right now. Also, see the paragraph above.
>
> Oh, so you _do_ know how to fix it properly:
Well, yes, but it doesn't fix it completely. Try the following
scenario:
* 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.
+ 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.
+ Everything still works.
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.
> - Make ENOTSUP and EOPNOTSUPP have different values in the header
> - Ensure that the implementations with the current symbol versions
> continue to return the old value to preserve binary compatibility
> - Create a new version for every affected function that does the desired
> error-code remapping
>
> So do it and propose a patch to upstream (or hire someone to do it for
> you). Handwaving and posting completely broken patches will not help.
> (Oh, and be prepared for Ulrich Drepper rejecting this exact change, as
> he already did in 1999).
I'd be happy to do it. However, I think Ulrich Drepper and the FSF will
not accept my patch without copyright assignment, and I don't do
copyright assignment, nor do I require others to do so. If the FSF
wants to waive that requirement, I'll be happy to do it, but I'm not
going to waste time on code that the FSF won't accept if I have to send
it upstream.
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. 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.
> > If and when that happens, my code will be broken, and I will be happy to
> > fix it. Expecting that I act as if something will happen, when I cannot
> > be certain it will, is silly.
>
> By the same argument, expecting that ENOTSUP and EOPNOTSUPP having
> different values in the future, when you cannot be certain they will
> (i.e. you haven't written a patch that got accepted upstream, and you
> have forced every Linux user to upgrade), is silly. So you should fix
> your code _now_, and remove the extra handling of ENOTSUP/EOPNOTSUPP
> if/when they will have separate values.
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.
If glibc didn't define that constant, then I couldn't be sure that the
codes were different (unless, of course, glibc claimed to support
Unix98/SUSv2 or newer). And AFAICT, there is no constant for LSB
compliance, so I have no way of even being able to tell whether glibc is
compliant with that, either. Not that I care about the LSB, but there's
really no way that I could, even if I wanted to attempt such compliance.
And even if I change my code, the bug will still be there; it just won't
affect my code. I have, BTW, changed my code so that it accepts such
breakage unless one of the following is true:
* the environment variable _POSIX2_VERSION is set to 200112
* the environment variable POSIXLY_PEDANTIC is set and non-empty
* the environment variable POSIXLY_CORRECT is set and non-empty
However, the first two are true on my system.
Attachment:
signature.asc
Description: This is a digitally signed message part