I think that's somewhat overly reductive. A significant portion (maybe 1/3-1/2?) of the article is devoted to describing mechanisms by which an ABI could be evolved, including a new (?) mechanism implemented in the author's Clang fork and submitted to the C committee ([0] in the blog post, currently on revision 8 [1]). Sure, it isn't a perfect solution, but as the author says:
> at least we’ll finally have the chance to have that discussion [about breaking ABI] with our communities, rather than just being outright denied the opportunity before Day 0.
Because it imagines that no library other than libc has an ABI that depends on intmax_t.
Suppose I have a libfoo that has a public function that takes an intmax_t parameter. Or that has a public struct with an intmax_t field. It will be compiled for a particular definition of intmax_t. If you try to link it with a program that uses a different definition, it will fail.
The article's solution with the "MY_LIBC_NEW_CODE" define cannot work because no existing C code knows about "MY_LIBC_NEW_CODE".
The proposed mechanism is somewhat useful to a library that wants to provide multiple incompatible implementations of a function. (But this is mostly only interesting for libc implementations that need to handle historic incompatibilities between all the various Unix specs. Other libraries can just give their new, incompatible function a new name.) It's useless if you want to make an incompatible change to a type definition.
> Because it imagines that no library other than libc has an ABI that depends on intmax_t.
I don't get quite the same impression. The sense I get is more that such a change would basically need to happen "bottom-up":
> Some of [the scenarios that aren't fixed by this proposal] are just the normal dependency management issues. If you build a library on top of something else that uses one of the changed types (such as intmax_t or something else), then you can’t really upgrade until your dependents do.
> <snip>
> For those of us in large ecosystems who have to write plugins or play nice with other applications and system libraries, we’re generally the last to get the benefits.
In which case the benefit of the proposal (as far as I understand) is that such bottom-up changes can occur without forcibly breaking other consumers.
It was never really possible to compile a library with one C compiler and expect it to link against code produced by another C compiler, unless both compilers happen to agree on specific ABI details that are either defined outside the C standard or not at all.
And to be honest, this sort of compiler-specific ABI interoperability is a non-problem that doesn't need solving, it's at most relevant for software developers of closed source libraries who distribute the libraries as precompiled blobs. But those must be stamped out for different target-triples anyway.
Compiler interoperability is the only ABI related problem area that's remotely in the scope for the C standard, but IMHO not even that (it's really not a problem that needs solving).
Ultimately any ABI discussions need to happen between CPU and OS vendors, compiler toolchains implement whatever comes out of those discussions.
> Compiler interoperability is the only ABI related problem area that's remotely in the scope for the C standard
idk, given how ABI impacts the evolution of C I think it's not unreasonable to provide a mechanism by which ABI can be evolved even if it's not specifically for compiler interop.
> Ultimately any ABI discussions need to happen between CPU and OS vendors, compiler toolchains implement whatever comes out of those discussions.
I think part of the article author's reasoning for proposing this feature is that toolchains have implemented something like this feature to try to address ABI issues and that the rest of the ecosystem could benefit from a similar technique.
Huh, compiler interoperability is extremely useful. It usually works by ABI groups defining a common ABI for each architecture and compilers then following these ABIs (although not required a compilers that does not is poor)
It's useful for closed-source developers who want to sell their libraries as precompiled binary blobs for static linking, but as soon as MSVC is involved that idea of "one library for different compilers" is out the window anyway ;)
For areas like application plugins via DLLs it's the OS ABI that matters.
I don't understand this comment. There are well-defined ABIs for many platforms. Sometimes there is a defacto ABI defined by the first compiler supporting this platform, but generally there ABI groups that agree on a common ABI for each architecture. This then allows code compiled by different compiler to be linked against common libraries - not just glibc. I can compile my projects with either clang, gcc, or some other compiler and link statically or dynamically against all the same libraries distributed by my distribution regardless of which compiler was used to compile them. This is extremely useful.
The issue is that a programmer is allowed to declare a function on its own without including the header, but then a function aliasing feature would not be visible and does not help. But if we waived this allowance, then a simple macro would do the job as well.
I think the most recent revision of the proposal basically says it not helping for such use cases is intentional? e.g., from Section 4.4.1. Standard Library Redeclaration [0]:
> Thankfully, we are not particularly concerned about the ability to upgrade this [user-redeclared stdlib] function: users who are declaring Standard Library functions without including the header like this are doing this strictly as experts. They have a strong expectation of what symbol they are getting from their distribution. Transparent aliases are meant to be used for functions which rely on type definitions or structures which may change, prompting the need to provide updated global variables and updated functions without breaking old binaries.
> <snip>
> Therefore, we do not do anything to support or inhibit such declarations. Implementations looking to keep such declarations working from older versions of code should consider leaving those old symbols within their binary artifacts (system tables, shared/static libraries, etc.) to continue supporting such a use case; this proposal is not going to address it or the myriad of other issues around this (such as strong/weak symbols and other attributes/aliasing issues).
To be fair, that section is talking about the stdlib specifically, but nothing jumps out to me as precluding it applying to libraries in general.
Conceptually intmax_t is a generic type of the form intmax_t<T>. Since C does not have generics, the T is chosen by the compiler during compile time.
But this means that the first time you compile any shared library with an intmax_t parameter or return value in one of its functions, you have permanently baked in the type parameter T to whatever the compiler chose it to be at that moment in time.
You cannot retroactively change intmax_t even if you change the symbols, because intmax_t runs into the same problem any generics system does, you cannot retroactively add instantiations for future types that were not explicitly compiled into the dynamic library.
Even if C gets generics and intmax_t would become obsolete either way, because you don't need intmax_t<T>, you can just have T.
intmax_t is only interesting for choosing the T and even then it is only interesting inside function implementations and never in their signatures.
So my conclusion is that intmax_t was a failed attempt at trying to be "clever" with the idea of introducing generics without introducing generics. This is an idea that is so doomed that anyone trying to rescue it, didn't really understand the problem with intmax_t.
> This is an idea that is so doomed that anyone trying to rescue it, didn't really understand the problem with intmax_t.
The C committee doesn't want to rescue intmax_t. If they had a time machine most members would prevent it ever being added. But it was and now it can't be removed; it takes decades to get breaking changes into the standard.
intmax_t is a thornier problem than time_t and needs a more comprehensive approach that requires some careful assistance from the C standard itself. There's no completely fixing the mess. The goal is to find an acceptable solution that allows everybody to begin to move past intmax_t given the various technical and practical constraints. The goal is not to find a solution that allows for expanded use of intmax_t, at least not in the standard, though it may be the case it can never completely go away.
I think the bigger issue is time_t, and I have, in fact wrote comments that literally state the code is "best before Jan 19, 2038." Said code may never be recompiled since it will trigger regulatory certification.
Even this is too simplistic. While C compilers normally use the OS ABI, there is nothing that requires them to do this, and other languages don't. Of course, when you need to call functions provided by the OS, you have to do so following the OS ABI; but calls between functions written in your own language, even in different libs, don't need to follow this same rule.
