Hmm. Well, I was assuming that glibc was following the spec all along but just changed some implementation detail that mattered because Adobe wasn't following the spec all along.
I think there's an argument to be made that the way an API is implemented is an implicit contract that ought to be upheld. But that's not the arugment I see being made.
Anyway, this level of detail is below the scope of the "specs vs pragmatism" debate that's going on.
I think there's an argument to be made that the way an API is implemented is an implicit contract that ought to be upheld.
That sounds wrong to me. If your consumers have to rely on assumptions beyond what's provided in the contract of the API, your API is leaky and/or broken.
[edit] I understand the pragmatism necessary in the case of the glibc issue, but to clarify my point I disagree with the general assertion I'm quoting.
Right, the memcpy() API is leaky because it leaves some things unspecified. You can deduce the implementation by providing various inputs to it that have "undefined behavior". This is a common problem in C, and there are usually functions that avoid it (Linus recommends memmove).
Hmm. Well, I was assuming that glibc was following the spec all along but just changed some implementation detail that mattered because Adobe wasn't following the spec all along.
I think there's an argument to be made that the way an API is implemented is an implicit contract that ought to be upheld. But that's not the arugment I see being made.
Anyway, this level of detail is below the scope of the "specs vs pragmatism" debate that's going on.