2 ms·
it was glibc's bad behavior it was depending on Hmm. Well, I was assuming that glibc was following the spec all along but just changed some implementation deta
by javert 16y ago
it was glibc's bad behavior it was depending on
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.
- ldh 16y agoI 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.
- devinj 16y agoRight, 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).
- krakensden 16y agoThe worst part is that the change is only a win on Core i* processors. It makes things slower on Atom.