3 ms·

I don’t agree. The C ABI is specified in a spec that Linux adopts (eg the x86-psabi), and it is what allows all software using this abi (from assembly to C to

I don’t agree. The C ABI is specified in a spec that Linux adopts (eg the x86-psabi), and it is what allows all software using this abi (from assembly to C to Rust) to eg Interface with each other. Linux could write an ABI spec for Rust on its platform today and add a patch to the Rust compiler (or to a C++ comoiler) to adhere to this ABI. Nobody has done this, and from many povs this is something that does not make much sense doing, but it’s up to the platform to specify how binary software communicates with each other. Linux only specifies this for C, and that’s what Rust software currently does and has to use on Linux.

bregma 6y ago
In GNU/Linux it's the GNU part that supplies the C ABI. The GNU compiler collection provides it, and the GNU libc uses it talk with the Linux kernel, usually through traps appropriate to the CPU. The LLVM toolchain (and other alternatives, like ICC) conform to this de facto standard. The GNU devs designed their ABI long before Linux came along and it is mostly inherited from even older OSes like BSD and SVr4 and developed refined and adapted over decades by a common community of interests. If you're going to criticise GNU/Linux for not providing a Rust ABI, make sure you're aiming at the GNU part. The Linux part doesn't care.
- SAI_Peregrinus 6y ago
  At the same time the C ABI is not part of the C standard. It's a GNU thing (or a Microsoft thing for Windows, or an Apple thing for Mac, or...). While they require the compiler to provide a stable ABI there's nothing preventing C20 (or future versions) from breaking existing C ABIs. It's not really right to talk about "the" C ABI, rather there's the x86 GCC ABI and the x86_64 GCC ABI and the x86 MSVC ABI and the MIPS GCC ABI and the... That's why compilers have target "triples" (now more than 3 items): <CPU architecture><subarchitecture>-<vendor>-<os/system>-<abi>. So you might have ARMv7m-st-none-eabi for some embedded STM32 bare-metal code and x86_64-pc-linux-gnu for Linux. All C, all different ABIs.

bregma 6y ago

In GNU/Linux it's the GNU part that supplies the C ABI. The GNU compiler collection provides it, and the GNU libc uses it talk with the Linux kernel, usually through traps appropriate to the CPU. The LLVM toolchain (and other alternatives, like ICC) conform to this de facto standard. The GNU devs designed their ABI long before Linux came along and it is mostly inherited from even older OSes like BSD and SVr4 and developed refined and adapted over decades by a common community of interests. If you're going to criticise GNU/Linux for not providing a Rust ABI, make sure you're aiming at the GNU part. The Linux part doesn't care.

SAI_Peregrinus 6y ago
At the same time the C ABI is not part of the C standard. It's a GNU thing (or a Microsoft thing for Windows, or an Apple thing for Mac, or...). While they require the compiler to provide a stable ABI there's nothing preventing C20 (or future versions) from breaking existing C ABIs. It's not really right to talk about "the" C ABI, rather there's the x86 GCC ABI and the x86_64 GCC ABI and the x86 MSVC ABI and the MIPS GCC ABI and the... That's why compilers have target "triples" (now more than 3 items): <CPU architecture><subarchitecture>-<vendor>-<os/system>-<abi>. So you might have ARMv7m-st-none-eabi for some embedded STM32 bare-metal code and x86_64-pc-linux-gnu for Linux. All C, all different ABIs.