8 ms·

Thousands of words that boil down to "intmax_t isn't ABI-stable". Who knew? (Everybody.)

by codeflo 1mo ago

aw1621107 1mo ago
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. [0]: https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2901.htm https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2901.htm [1]: https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3913.htm https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3913.htm
- uecker 1mo ago
  The mechanism actually does not solve the problem it claims to solve.
  - aw1621107 1mo ago
    How so?
    - uecker 1mo ago
      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.
      - aw1621107 1mo ago
        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. [0]: https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3913.htm#design-compatibility-redeclaration https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3913.htm#d...
        uecker 1mo ago
        Indeed, it now admits this. But what problem is this then really solving?
        aw1621107 1mo ago
        > But what problem is this then really solving? Well, I'd presume that's what the paper's "Introduction & Motivation" section is for. Do you take issue with the authors' statements there?
        uecker 1mo ago
        Yes, it does not solve the problems described there.
    - pdw 1mo ago
      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.
      - aw1621107 1mo ago
        > 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.
        flohofwoe 1mo ago
        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.
pjmlp 1mo ago
Not really, because many don't even know there isn't such thing as C ABI, rather the OS ABI, when the OS happens to be written in C.
- simiones 1mo ago
  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.
prussian 1mo ago
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.
imtringued 1mo ago
intmax_t is a dumb idea. 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.
- wahern 1mo ago
  > 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.
  - cryptonector 1mo ago
    I'd rather `intmax_t` be deprecated and marked for removal. It was a terrible mistake.

Thousands of words that boil down to "intmax_t isn't ABI-stable". Who knew? (Everybody.)

by codeflo 1mo ago

Thousands of words that boil down to "intmax_t isn't ABI-stable". Who knew? (Everybody.)

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. [0]: https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2901.htm https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2901.htm [1]: https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3913.htm https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3913.htm

uecker 1mo ago
The mechanism actually does not solve the problem it claims to solve.
- aw1621107 1mo ago
  How so?
  - uecker 1mo ago
    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.
    - aw1621107 1mo ago
      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. [0]: https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3913.htm#design-compatibility-redeclaration https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3913.htm#d...
      - uecker 1mo ago
        Indeed, it now admits this. But what problem is this then really solving?
        aw1621107 1mo ago
        > But what problem is this then really solving? Well, I'd presume that's what the paper's "Introduction & Motivation" section is for. Do you take issue with the authors' statements there?
        uecker 1mo ago
        Yes, it does not solve the problems described there.
  - pdw 1mo ago
    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.
    - aw1621107 1mo ago
      > 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.
      - flohofwoe 1mo ago
        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.

pjmlp 1mo ago

Not really, because many don't even know there isn't such thing as C ABI, rather the OS ABI, when the OS happens to be written in C.

simiones 1mo ago
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.

prussian 1mo ago

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.

imtringued 1mo ago

intmax_t is a dumb idea. 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.

wahern 1mo ago
> 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.
- cryptonector 1mo ago
  I'd rather `intmax_t` be deprecated and marked for removal. It was a terrible mistake.