7 ms·

It depends on how we define the ABI. I see it as a set of client-visible invariants that they rely on. In my world, glibc changed the client's visible invariant

by pg83 29d ago

It depends on how we define the ABI. I see it as a set of client-visible invariants that they rely on. In my world, glibc changed the client's visible invariants, breaking the client. The client works on one glibc-based host, but not on another. What is this if not "a case of cross-distro glibc issues?" Overall, both of our points of view on compatibility were discussed well in that thread; we probably shouldn't repeat ourselves. :)

account42 29d ago
ABI is not "whatever happens to work with this distro" but "what programs that comply with the API contract compile to". Overlapping memcpy arguments is an API contract violation and thus not something covered by the ABI either. This distinction is the entire reason why C has a separate memmove function. You can't just make up your own imaginary ABI contract and then blame the system when it doesn't fulfill it. That's going to result in self-inflicted plain on any OS.
- pg83 29d ago
  It's so good that Linus thinks differently!
  - ninkendo 29d ago
    Even Linus’s comments in that bug hedge things a bit: > and that if people depend on interfaces we exported having side effects that weren't intentional, we try to fix things so that they still work unless there is a major reason not to. (Emphasis mine.) In the Flash case, they changed the direction memcpy works in, in a way that didn’t actually improve any performance (Linus did benchmarks to show it) and Linus’s point was that there’s no upside to the change, and only downsides, so on the whole it makes no sense to keep the changed memcpy. You could imagine plenty of scenarios where existing behavior truly is broken, and show that no popular software depends on the brokenness (which is why distros are in a great place to do these kinds of smoke tests, they have thousands of packages they can test), and make a judgement call. A “zero regressions no matter what” policy is impossible in practice due to Hyrum’s law, at some point you have to use common sense and draw the line somewhere sensible.
ninkendo 29d ago
> It depends on how we define the ABI. I see it as a set of client-visible invariants that they rely on By that definition, any change of any kind will break ABI, Hyrum’s law and spacebar heating and all that.
vlovich123 28d ago
Did the distro apply a patch to glibc that broke things that others did not? Or did they pick up a newer version of glibc that other distros hadn’t? Yes, different distributions run on different versions of glibc. And different versions of glibc may have subtle differences in runtime behavior. That’s still ultimately a glibc back compost issue, not some kind of bug specific to glibc.

by pg83 29d ago

account42 29d ago

ABI is not "whatever happens to work with this distro" but "what programs that comply with the API contract compile to". Overlapping memcpy arguments is an API contract violation and thus not something covered by the ABI either. This distinction is the entire reason why C has a separate memmove function. You can't just make up your own imaginary ABI contract and then blame the system when it doesn't fulfill it. That's going to result in self-inflicted plain on any OS.

pg83 29d ago
It's so good that Linus thinks differently!
- ninkendo 29d ago
  Even Linus’s comments in that bug hedge things a bit: > and that if people depend on interfaces we exported having side effects that weren't intentional, we try to fix things so that they still work unless there is a major reason not to. (Emphasis mine.) In the Flash case, they changed the direction memcpy works in, in a way that didn’t actually improve any performance (Linus did benchmarks to show it) and Linus’s point was that there’s no upside to the change, and only downsides, so on the whole it makes no sense to keep the changed memcpy. You could imagine plenty of scenarios where existing behavior truly is broken, and show that no popular software depends on the brokenness (which is why distros are in a great place to do these kinds of smoke tests, they have thousands of packages they can test), and make a judgement call. A “zero regressions no matter what” policy is impossible in practice due to Hyrum’s law, at some point you have to use common sense and draw the line somewhere sensible.

ninkendo 29d ago

> It depends on how we define the ABI. I see it as a set of client-visible invariants that they rely on By that definition, any change of any kind will break ABI, Hyrum’s law and spacebar heating and all that.

vlovich123 28d ago

Did the distro apply a patch to glibc that broke things that others did not? Or did they pick up a newer version of glibc that other distros hadn’t? Yes, different distributions run on different versions of glibc. And different versions of glibc may have subtle differences in runtime behavior. That’s still ultimately a glibc back compost issue, not some kind of bug specific to glibc.