[HN Gopher] To Save C, We Must Save ABI (2022)
___________________________________________________________________
To Save C, We Must Save ABI (2022)
Author : karsinkk
Score : 55 points
Date : 2023-06-08 21:19 UTC (2 days ago)
(HTM) web link (thephd.dev)
(TXT) w3m dump (thephd.dev)
| dang wrote:
| Discussed at the time:
|
| _To save C, we must save ABI_ -
| https://news.ycombinator.com/item?id=30660528 - March 2022 (128
| comments)
| zabzonk wrote:
| 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.
| SAI_Peregrinus wrote:
| Yep, the "target triple" (poorly named) defines _a_ C ABI.
| Every target triple defines a new C ABI.
| jmclnx wrote:
| 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.
| dang wrote:
| I'm sorry but I don't understand that and from a very
| superficial skim of the article it doesn't seem obvious that
| the title should say C++.
| detaro wrote:
| It shouldn't. The article picks up from a C++-centric
| discussion and looks at it from the perspective of C.
| somat wrote:
| The less source you have the more important having a stable ABI
| is.
|
| 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.
| marcosdumay wrote:
| 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.
| badsectoracula wrote:
| 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).
| tialaramex wrote:
| > 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.
| TazeTSchnitzel wrote:
| Rust basically doesn't have dynamic linking though and is
| relying on underlying platforms having stable ABIs.
| bluejekyll wrote:
| 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).
___________________________________________________________________
(page generated 2023-06-10 23:02 UTC)