Because this library is so very widely used, in practice it is subject to Hyrum's law ABI breaks far beyond what is characterised in the SO_NAME. At the extreme Hyrum's law gets you "spacebar heating", this is not a demand that somehow nothing must change, but an acknowledgement of our reality.<p>Basically even though Daniel might say "I didn't change the ABI" if your code worked before and now it didn't, as far as you're concerned that's an ABI break. This particularly shows up for changed defaults and for removing stuff that's "unused" except that you relied on it and so now your code doesn't work. Daniel brings up NPN because that seems easy for the public Internet but there have been other examples where a default changed and well... too bad, you were relying on something and now it's changed, but you should have just known to set what you wanted and then you'd have been fine.
I'm a bit confused with the usage of ABI here. I thought compatibility between apps and libs is on the API level, while the ABI sits between machine (cpu intructions) and low level (curl?) lib?
> “third party” transfers over FTP,<p>Ohh that takes me back, that feature was used heavily in the FXP warez scene (the one the proper warez people looked down on), you’d find vulnerable FTP servers to gain access to, and the best ones would support this. That way you could quickly spread releases over multiple mirrors without being slowed down by your home internet.
> The Debian project even decided to override our decision “no, that is not an ABI breakage” and added a local patch in their build that lowered the SONAME number back to 3 again in their builds. A patch they would stick to for many years to come.<p>I get mad even reading about this. If I was in his shoes I'd demand they fork and rename their implementation. Too many times we hear about over zealous debian patches being the source is issues.
What are some things you could do in a C project to <i>cause</i> ABI breakage?<p>I ask this because I'd like to know what practices I might want to avoid to guarantee that there is no ABI breakage in my C project.
> Before this release, you could use curl to do “third party” transfers over FTP, and in this release you could no longer do that. That is a feature when the client (curl) connects to server A and instructs that server to communicate with server B and do file transfers among themselves, without sending data to and from the client.<p>That sounds like a super useful feature that would be great if more FTP servers supported it. I guess FTP itself is a dying protocol these days, but it's extremely simple and does what it says on the tin.
Unfortunately this is no longer maintained, but it's interesting nonetheless:
<a href="https://abi-laboratory.pro/?view=timeline&l=curl" rel="nofollow">https://abi-laboratory.pro/?view=timeline&l=curl</a>
libcurl is part of the macOS API and de-facto standard on any Linux box and commonly available on BSD boxen as well. Microsoft has been shipping curl.exe for a while as well, though not the library.<p>If Microsoft would also ship the library in %system32%, we would have a truly cross-platform and stable, OS-provided and -patched high-level network protocol client.<p>(So that probably won't happen)