Bug#227386: libc6-dev: ENOTSUP==EOPNOTSUPP, which violates SUSv3

[Gabor Gombas <gombasg@sztaki.hu>]

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.

> 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:

- 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).

> 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.

Gabor

-- 
     ---------------------------------------------------------
     MTA SZTAKI Computer and Automation Research Institute
                Hungarian Academy of Sciences
     ---------------------------------------------------------