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