Re: [PATCH] Fix up LD_* vars behaviour

[Roland McGrath <roland at hack dot frob dot com>]

> > If we made a mistake on an implementation and it's been out in the
> > wild for some time, and people do depend upon it, we're essentially
> > stuck supporting it forever whether we like it or not.
> 
> Agreed.

There are two categories here.  

If something was always explicitly unspecified or undefined and we didn't
make an explicit choice to make it more predictable in the glibc API, then
people depending on whatever behavior they observed were wrong to do so.
We can change it when it's worthwhile for other reasons.  Of course,
practical considerations of common usage may influence our choices.  An
excellent example is the recent memcpy change.  Developers who thought
memcpy was memmove were wrong, even though it happened to be the case that
glibc's memcpy reliably behaved as memmove for years.  We changed it and it
was entirely fine that we did.  But there were practical problems affecting
many users, so we found a middle ground: those developers were still wrong,
but glibc users using existing binaries from those developers deserved that
we help them work around the problem, so we did.

What Dave mentioned is the second category, for which I don't know of an
example off hand.  That is, we always had consistent behavior and there was
no particular reason to think that there was an accepted range of variation
in the behavior a future library might exhibit, but we were violating a
specification to which we otherwise attempt to conform.  If such a case
arises, we'll have to figure out how to handle it.  Standards do matter,
but users also matter, and it's our responsibility to bridge the gap
appropriately in each case.

> - If we release it, and users use it, and can be reasonably expected
> to have it keep working either by ambiguity in the standard or
> documentation, then we must support it.

That is too broad.  There is plenty of ambiguity in documentation,
especially in absent documentation.  Every case is a balancing test
and there is no simple rule that relieves us from applying our judgment.

> Roland, unfortunately I feel that your position with respect to the
> linux man pages project is not correct. As a project we have failed to
> document our own interfaces and over the years the linux man pages has
> become *the* canonical documentation for the GNU Libc interfaces like
> LD_* vars passed to ld.so.1. Whether we agree with them or not is
> irrelevant at this point, we need to think about our users, and our
> users for lack of our own documentation, rely on the linux man pages.

I disagree utterly.  We cannot be held hostage to what some uncoordinated
other people out in the world have done.  There is a long history of Linux
man pages being thoroughly wrong.  Unfortunately, there is also a long
history of some glibc features lacking documentation in the manual, and of
the manual not always being right.  When the manual does not comport with
the reality or intent of the code, then we change the manual.  When the
manual doesn't say anything at all, then the appropriate level of
compatibility and the reasonableness of a given user's expectations must be
subject to our careful judgment.  There are no easy rules.

What users mostly do in fact is just experiment and observe, and then
expect the behavior they observed to be preserved in the future.
Sometimes those expectations are reasonable and sometimes they are not.
We are responsible to all the users, past, present, and future--not just
particular vociferous past users who rail against some change.  We are
the experts and it's our responsibility to judge what's best overall,
not that of some subset of users and not that of some man-page writer.
Sometimes slavish compatibility with the past bad assumptions of
application developers or outside documentation writers does a
disservice to the users at large.  That's one reason we have major
releases and minor releases.  Certainly controversial cases don't change
in minor releases.


Thanks,
Roland