To Save C, We Must Save ABI (2022)(thephd.dev)
thephd.dev
To Save C, We Must Save ABI (2022)
https://thephd.dev/to-save-c-we-must-save-abi-fixing-c-function-abi
3 comments
ABI stability implies API stability and breaking the API wont help you if you have the source unless you plan to go and change every single project using the broken API in existence. Considering how many years it took for multiple projects to manage the Gtk2->Gtk3 API breakage (with some projects deciding to just not bother - see Ardour) this isn't something to handwave with a "just a concern for closed source software".
> The openbsd project is actively hostile to closed source commercial programs with their laissez-faire attitude toward abi stability
OpenBSD has the "benefit" of having everything in a single repository and when they break something they can also fix any uses in the same commit. I'm also certain that because of that they rarely actually break things that would need a huge number of updates, so that single repository also acts as a "do we really need this?" filter.
This is an exceptional case that doesn't apply to the overwhelming majority of projects out there which are projects that either expose an API/ABI of their own or projects that consume 3rd party API/ABIs that they have no control over.
> I have this enormous stable of open source software. and it all runs just fine.
This is because others are doing the work of keeping that software working on OpenBSD but once you encounter a situation where you need some software that hasn't been updated for a while to keep up with OpenBSD's API breakage, it'll become apparent that having access to the source code isn't some magic bullet and someone will need to do the work to bring it up to date.
Of course not having access to the source code is worse, but having the code is only one part of keeping things working, not the entire story. And IMO when we're discussing about projects that mainly or completely run by volunteers in their free time, i think it is a good idea to avoid situations where APIs and ABIs break so that limited free time is spent doing more useful and/or interesting things (i do not think anyone really likes fixing API/ABI breakage).
> The openbsd project is actively hostile to closed source commercial programs with their laissez-faire attitude toward abi stability
OpenBSD has the "benefit" of having everything in a single repository and when they break something they can also fix any uses in the same commit. I'm also certain that because of that they rarely actually break things that would need a huge number of updates, so that single repository also acts as a "do we really need this?" filter.
This is an exceptional case that doesn't apply to the overwhelming majority of projects out there which are projects that either expose an API/ABI of their own or projects that consume 3rd party API/ABIs that they have no control over.
> I have this enormous stable of open source software. and it all runs just fine.
This is because others are doing the work of keeping that software working on OpenBSD but once you encounter a situation where you need some software that hasn't been updated for a while to keep up with OpenBSD's API breakage, it'll become apparent that having access to the source code isn't some magic bullet and someone will need to do the work to bring it up to date.
Of course not having access to the source code is worse, but having the code is only one part of keeping things working, not the entire story. And IMO when we're discussing about projects that mainly or completely run by volunteers in their free time, i think it is a good idea to avoid situations where APIs and ABIs break so that limited free time is spent doing more useful and/or interesting things (i do not think anyone really likes fixing API/ABI breakage).
> ABI stability implies API stability
Yes, but not vice versa. Rust's language and standard library for example promises API stability, but not ABI stability. Since it doesn't promise ABI stability, the actual implementation can be radically different so long as the API you were promised still works and nobody has to go around "changing every single project" because there aren't any changes, for source code nothing changed.
Yes, but not vice versa. Rust's language and standard library for example promises API stability, but not ABI stability. Since it doesn't promise ABI stability, the actual implementation can be radically different so long as the API you were promised still works and nobody has to go around "changing every single project" because there aren't any changes, for source code nothing changed.
Rust basically doesn't have dynamic linking though and is relying on underlying platforms having stable ABIs.
It does have dynamic linking,
--crate-type=dylib.
Sure, but the ABI isn't stable and you're expected to recompile all your dependencies in one go. You can make a C-style ABI for your crate but that's not very common.
That is another matter.
I believe Rust guarantees ABI stability through the C FFI, what it doesn’t guarantee is a Rust <—> Rust stable ABI (unless you use Rust <-> C <-> Rust).
That's only if you have a single compiler.
On practice, ABI expressivity (not so much stability) is something very important that people have insisted on overlooking for decades because of that single-compiler fallacy.
On practice, ABI expressivity (not so much stability) is something very important that people have insisted on overlooking for decades because of that single-compiler fallacy.
Discussed at the time:
To save C, we must save ABI - https://news.ycombinator.com/item?id=30660528 - March 2022 (128 comments)
To save C, we must save ABI - https://news.ycombinator.com/item?id=30660528 - March 2022 (128 comments)
Thanks.
But the title seems to be misleading. the title should be "to save c++, ....", c++ is not c nor is c the same as c++.
In the old link you provided, no one mentioned this is strictly about the c++ ABI.
>That's why I think C++ should be forked... Not to mention microsoft is probably the main culprit here.
But jokoon came close with the above quote.
But the title seems to be misleading. the title should be "to save c++, ....", c++ is not c nor is c the same as c++.
In the old link you provided, no one mentioned this is strictly about the c++ ABI.
>That's why I think C++ should be forked... Not to mention microsoft is probably the main culprit here.
But jokoon came close with the above quote.
and as i said back then:
> I'd just like to clarify that it's specific _compilers_ that produce code that complies with an ABI specification (or don't). Neither the C nor the C++ language standards specify an ABI format.
> I'd just like to clarify that it's specific _compilers_ that produce code that complies with an ABI specification (or don't). Neither the C nor the C++ language standards specify an ABI format.
Yep, the "target triple" (poorly named) defines a C ABI. Every target triple defines a new C ABI.
Conversely the more source you have the less important a stable binary interface is.
I use a lot of openbsd. The openbsd project is actively hostile to closed source commercial programs with their laissez-faire attitude toward abi stability. However I have this enormous stable of open source software. and it all runs just fine.