Mike Hearn wrote:
I believe the point of view of the glibc maintainers is as put by Ulrich Drepper in his paper "Good practices in library design, implementation, and maintenance", chapter three:The problems start when you have one symbol with multiple versions: this is worse than just renaming the symbol because while old *binaries* continue to work, if you then compile the same sources on a newer system they get the new semantics automatically which could break them.
Eg take the example of regexec, which has a new overloaded version of GLIBC_2.3.4 - the new version was introduced because now if you specify unknown eflags it returns with error whereas before I guess it didn't.
That keeps old binaries working, but what if you then take old code
and compile it on a newer system? Well now the code doesn't get the
semantics it expects and breaks.
"One sort of change which should always be made without hesitation is bug fixes. They should be made event if the API is changed. Some people argue that some programs are depending on the old, broken behaviour. But this argumentation is flawed. Equally well there are programs which depend on the correct behaviour, written by people who read the specification. No program which depends on broken behaviour deserves protection. If a programmer has found such a discrepancy and changed the application to use it instead of reporting it to the library maintainer s/he gets what s/he deserves."
http://people.redhat.com/drepper/goodpractice.pdf
-- Pedro Lamarão
