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).

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.

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.

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.