4 ms·

Nope, API compatibility is when you write the code, and ABI compatibility is what happens to already compiled code, but still between app and library. Say you c

Nope, API compatibility is when you write the code, and ABI compatibility is what happens to already compiled code, but still between app and library. Say you compiled your app against libcurl.so.4 file taken from curl 7.88 packaged by Debian. What happens when, far in the future, you will move your executable file, without recompiling, to a system which has curl 12345.67, but the file will still be libcurl.so.4? It should work fine, that is, the library should export the same symbols (maybe some more added), with more or less the same functionality. Possibly implemented differently, maybe accepting more flags, but the stuff that is there, will be there. To parent's downvoters: would you kindly cut him some slack? It's OK to ask if you don't know. https://xkcd.com/1053/ https://xkcd.com/1053/

DanielHB 2y ago
Just for a small example how both are not the same, in your C library if you move the positions of a field in a struct it can actually break ABI compatibility (meaning you need to recompile your software), but not API compatibility (meaning you don't need to update your code).
- thrtythreeforty 2y ago
  And the opposite is true too: you can break API (by renaming a field) while preserving the ABI (since it didn't move/change type).
  - NekkoDroid 2y ago
    You can also with certain type of APIs increase the size of structs and still be ABI compatible. This is usually done by encoding the size of the type as a member of the struct that is usually assigned via `x.size = sizeof(x)` and passed around as pointers. Takes real care to maintain that though. IIRC this appears somewhat frequently in Win32.
nuancebydefault 2y ago
Thanks for explaining, people! To me ABI immediately triggers the aarch64 / x86 etc vibes, but that indeed makes sense! Now I'm wondering if/how managed code of e.g. dotnet solves this issue, but that might be too much of a tangent.
- fowl2 2y ago
  There is a distinction in the dotnet world too. The docs[1] seem to refer to ABI as "Binary compatibility" and API "Source compatibility". Jon Skeet has some good examples [2] [1] https://learn.microsoft.com/en-us/dotnet/core/compatibility/categories https://learn.microsoft.com/en-us/dotnet/core/compatibility/... [2] https://codeblog.jonskeet.uk/2018/04/13/backward-compatibility-and-overloading/ https://codeblog.jonskeet.uk/2018/04/13/backward-compatibili...

DanielHB 2y ago

Just for a small example how both are not the same, in your C library if you move the positions of a field in a struct it can actually break ABI compatibility (meaning you need to recompile your software), but not API compatibility (meaning you don't need to update your code).

thrtythreeforty 2y ago
And the opposite is true too: you can break API (by renaming a field) while preserving the ABI (since it didn't move/change type).
- NekkoDroid 2y ago
  You can also with certain type of APIs increase the size of structs and still be ABI compatible. This is usually done by encoding the size of the type as a member of the struct that is usually assigned via `x.size = sizeof(x)` and passed around as pointers. Takes real care to maintain that though. IIRC this appears somewhat frequently in Win32.

nuancebydefault 2y ago

Thanks for explaining, people! To me ABI immediately triggers the aarch64 / x86 etc vibes, but that indeed makes sense! Now I'm wondering if/how managed code of e.g. dotnet solves this issue, but that might be too much of a tangent.

fowl2 2y ago
There is a distinction in the dotnet world too. The docs[1] seem to refer to ABI as "Binary compatibility" and API "Source compatibility". Jon Skeet has some good examples [2] [1] https://learn.microsoft.com/en-us/dotnet/core/compatibility/categories https://learn.microsoft.com/en-us/dotnet/core/compatibility/... [2] https://codeblog.jonskeet.uk/2018/04/13/backward-compatibility-and-overloading/ https://codeblog.jonskeet.uk/2018/04/13/backward-compatibili...