5 ms·

As a programmer, I'm not very fond of C, but C has two huge advantages over other languages: * It's everywhere * There's a standard ABI

jcelerier 6y ago
> * There's a standard ABI there's one ? the "C" ABI is just the ABI of whatever platform it's running on, which may or may not have funky behaviour that vendor-provided compilers kindly hide for you - functions being prepended with '_' on macOS, the two-dozen calling conventions on windows with i386, sysv and itanium ABIs... Do you think you can tell what's the ABI of struct foo some_function(struct bar); ? will bar be passed in a register, on the stack ? who knows, that depends on your platform, your compiler, etc etc. Things going cleanly on the stack is just a convenient lie that your first year comp. sci teachers tell you because it's too early to talk about how the real world works yet.
- pavlov 6y ago
  > the "C" ABI is just the ABI of whatever platform it's running on But typically the C ABI is the only stable ABI those platforms provide. That's a huge benefit.
  - brandmeyer 6y ago
    Apple's custom AArch64 ABI has entered the chat... https://developer.r-project.org/Blog/public/2020/11/02/will-r-work-on-apple-silicon/ https://developer.r-project.org/Blog/public/2020/11/02/will-... https://developer.apple.com/documentation/xcode/writing_arm64_code_for_apple_platforms https://developer.apple.com/documentation/xcode/writing_arm6...
    - setpatchaddress 6y ago
      "platform", not "ISA". Windows on Intel doesn't use the same ABI as linux.
      - StillBored 6y ago
        Windows doesn't even have a single calling convention... https://docs.microsoft.com/en-us/cpp/cpp/argument-passing-and-naming-conventions?view=msvc-160 https://docs.microsoft.com/en-us/cpp/cpp/argument-passing-an...
        jcelerier 6y ago
        and that is without counting Cygwin which IIRC uses another calling convention
        will4274 6y ago
        You mean 32 bit Windows. 64 bit Windows only has one calling convention.
- flohofwoe 6y ago
  The leading '_' before symbols isn't just a macOS thing, AFAIK this is the only "name mangling" that C does and from what I've seen so far it's the same across platforms and compilers. As far as the ABI goes: the important thing is that there is a standard ABI on a specific platform that all compilers on that platform agree on. Sounds kinda obvious, but it's not common in other languages.
  - jcelerier 6y ago
    > The leading '_' before symbols isn't just a macOS thing it definitely is - see e.g. https://github.com/llvm-mirror/lld/blob/master/lib/ReaderWriter/MachO/MachOLinkingContext.cpp#L874 https://github.com/llvm-mirror/lld/blob/master/lib/ReaderWri...
    - flohofwoe 6y ago
      Oh ok, that must be an extra leading underscore then, haven't stumbled over this yet though.
      - jcelerier 6y ago
        the only cases you stumble over it is if you're trying to do linking / symbol loading yourself manually (e.g. in my case it was because I was looking into JIT compilation mechanisms)
- sumtechguy 6y ago
  C was one of those write once compile anywhere bits they used to tell us. Then when we actually tried it we found every CRT was different on all of the platforms. Even something as ubiquitous as printf I think I have encountered at least 8 different versions of it. At least from compiler chain to compiler chain they are usually similar in calling conventions (but not always). But try mixing a msvcrt with a glib one and you are in for some fun... What is the nit of it is it almost works. You have a good shot at getting it to compile in a short amount of time. The rest of the work will be lots of time in ye old debugger and going over the docs for your platform. The fun part is you will find bugs that were there already, or are they just part of the platform, or were you using it wrong?
  - jesuscyborg 6y ago
    If you want a CRT that's compile-once run-anywhere for x86 then try cosmopolitan with actually portable executable. https://justine.storage.googleapis.com/ape.html https://justine.storage.googleapis.com/ape.html It even supports fork() on windows as of a few days ago: https://github.com/jart/cosmopolitan/commit/db33973e0aae7ffc2537991e372e3fc5e59608a7 https://github.com/jart/cosmopolitan/commit/db33973e0aae7ffc...
    - sumtechguy 6y ago
      That is 9 :) In effect it is yet another CRT and the idea is sound. But many times what I found was you may have one that works on say linux and windows and bsd. All the same 'code' but you dig under the covers a bit and it is a maze of ifdefs so each platform has its own quirks. For example threading between fork and createthread is on the surface not too different and you can wrap createthread with it (several libs did). But you dig into it a bit and you find portions that just do not map at all between the systems (usually with IPC and locks). At best they do not compile, slightly worse they return error codes, at worst they act like they work. A real good example of what I am talking about is the pthread library. It works up to a point but it is a very linux/bsd orientated library. There are some gaps in there from windows that just do not map and the other way around. What is worse is the docs on some of these do not talk about cross platform issues. Luckily you can see the source code of most of them and can tell what is going on. Annoying but one of the things I learned moving code between platforms is that each one has its own way of doing things. You can try to work against it or sit down and unwind what is going on, which takes time. I have even seen this sort of issue in python and java. Where you get down to some low level thing and it just is different on different platforms.
- int_19h 6y ago
  ABIs have always been platform-specific in that sense. C ABI is beneficial in that on any specific platform, it's interoperable - which is good enough, because native code has to be compiled for a specific platform, anyway. In your specific example, I don't really care how "struct foo" is passed, so long as all shared libraries compiled for that platform agree on how it's done. And we have that on C level today on all major platforms. Sure, there are compiler switches and language extensions that can break the ABI if you use them. But, well, you don't have to use them (at the interop boundary), and neither do your API clients.
pornel 6y ago
The ABI may come from C, but it's not limited to C. Many other languages have FFI and use the C ABI as the lowest common denominator. But the C ABI is awful to work with. The C language itself offers no help to guarantee ABI compatibility. What ABI it compiles for depends on headers, which may depend on a jungle of ifdefs and typedefs.
rwmj 6y ago
An advantage of Rust and Golang (and OCaml actually[1]) is they let you write to the C ABI. We've written both components that call into existing C ABI (nbdkit-{rust|golang}-plugin), and also Rust/Golang/OCaml shared libraries that present C ABI functions / structures to the world. [1] But you need to write a bit of C glue code for OCaml so it's not quite so seamless.
- bachmeier 6y ago
  And D. It works so well that the compiler has betterC mode: https://dlang.org/spec/betterc.html https://dlang.org/spec/betterc.html
- int_19h 6y ago
  Some form of C FFI has been standard for most languages that appeared after C became ubiquitous. Even something as dynamic and high-level as Python has ctypes.
sigjuice 6y ago
What standard ABI? If I look at the gcc man page, there is a large number of abi related knobs.

jcelerier 6y ago

> * There's a standard ABI there's one ? the "C" ABI is just the ABI of whatever platform it's running on, which may or may not have funky behaviour that vendor-provided compilers kindly hide for you - functions being prepended with '_' on macOS, the two-dozen calling conventions on windows with i386, sysv and itanium ABIs... Do you think you can tell what's the ABI of struct foo some_function(struct bar); ? will bar be passed in a register, on the stack ? who knows, that depends on your platform, your compiler, etc etc. Things going cleanly on the stack is just a convenient lie that your first year comp. sci teachers tell you because it's too early to talk about how the real world works yet.

pavlov 6y ago
> the "C" ABI is just the ABI of whatever platform it's running on But typically the C ABI is the only stable ABI those platforms provide. That's a huge benefit.
- brandmeyer 6y ago
  Apple's custom AArch64 ABI has entered the chat... https://developer.r-project.org/Blog/public/2020/11/02/will-r-work-on-apple-silicon/ https://developer.r-project.org/Blog/public/2020/11/02/will-... https://developer.apple.com/documentation/xcode/writing_arm64_code_for_apple_platforms https://developer.apple.com/documentation/xcode/writing_arm6...
  - setpatchaddress 6y ago
    "platform", not "ISA". Windows on Intel doesn't use the same ABI as linux.
    - StillBored 6y ago
      Windows doesn't even have a single calling convention... https://docs.microsoft.com/en-us/cpp/cpp/argument-passing-and-naming-conventions?view=msvc-160 https://docs.microsoft.com/en-us/cpp/cpp/argument-passing-an...
      - jcelerier 6y ago
        and that is without counting Cygwin which IIRC uses another calling convention
      - will4274 6y ago
        You mean 32 bit Windows. 64 bit Windows only has one calling convention.
flohofwoe 6y ago
The leading '_' before symbols isn't just a macOS thing, AFAIK this is the only "name mangling" that C does and from what I've seen so far it's the same across platforms and compilers. As far as the ABI goes: the important thing is that there is a standard ABI on a specific platform that all compilers on that platform agree on. Sounds kinda obvious, but it's not common in other languages.
- jcelerier 6y ago
  > The leading '_' before symbols isn't just a macOS thing it definitely is - see e.g. https://github.com/llvm-mirror/lld/blob/master/lib/ReaderWriter/MachO/MachOLinkingContext.cpp#L874 https://github.com/llvm-mirror/lld/blob/master/lib/ReaderWri...
  - flohofwoe 6y ago
    Oh ok, that must be an extra leading underscore then, haven't stumbled over this yet though.
    - jcelerier 6y ago
      the only cases you stumble over it is if you're trying to do linking / symbol loading yourself manually (e.g. in my case it was because I was looking into JIT compilation mechanisms)
sumtechguy 6y ago
C was one of those write once compile anywhere bits they used to tell us. Then when we actually tried it we found every CRT was different on all of the platforms. Even something as ubiquitous as printf I think I have encountered at least 8 different versions of it. At least from compiler chain to compiler chain they are usually similar in calling conventions (but not always). But try mixing a msvcrt with a glib one and you are in for some fun... What is the nit of it is it almost works. You have a good shot at getting it to compile in a short amount of time. The rest of the work will be lots of time in ye old debugger and going over the docs for your platform. The fun part is you will find bugs that were there already, or are they just part of the platform, or were you using it wrong?
- jesuscyborg 6y ago
  If you want a CRT that's compile-once run-anywhere for x86 then try cosmopolitan with actually portable executable. https://justine.storage.googleapis.com/ape.html https://justine.storage.googleapis.com/ape.html It even supports fork() on windows as of a few days ago: https://github.com/jart/cosmopolitan/commit/db33973e0aae7ffc2537991e372e3fc5e59608a7 https://github.com/jart/cosmopolitan/commit/db33973e0aae7ffc...
  - sumtechguy 6y ago
    That is 9 :) In effect it is yet another CRT and the idea is sound. But many times what I found was you may have one that works on say linux and windows and bsd. All the same 'code' but you dig under the covers a bit and it is a maze of ifdefs so each platform has its own quirks. For example threading between fork and createthread is on the surface not too different and you can wrap createthread with it (several libs did). But you dig into it a bit and you find portions that just do not map at all between the systems (usually with IPC and locks). At best they do not compile, slightly worse they return error codes, at worst they act like they work. A real good example of what I am talking about is the pthread library. It works up to a point but it is a very linux/bsd orientated library. There are some gaps in there from windows that just do not map and the other way around. What is worse is the docs on some of these do not talk about cross platform issues. Luckily you can see the source code of most of them and can tell what is going on. Annoying but one of the things I learned moving code between platforms is that each one has its own way of doing things. You can try to work against it or sit down and unwind what is going on, which takes time. I have even seen this sort of issue in python and java. Where you get down to some low level thing and it just is different on different platforms.
int_19h 6y ago
ABIs have always been platform-specific in that sense. C ABI is beneficial in that on any specific platform, it's interoperable - which is good enough, because native code has to be compiled for a specific platform, anyway. In your specific example, I don't really care how "struct foo" is passed, so long as all shared libraries compiled for that platform agree on how it's done. And we have that on C level today on all major platforms. Sure, there are compiler switches and language extensions that can break the ABI if you use them. But, well, you don't have to use them (at the interop boundary), and neither do your API clients.

pornel 6y ago

The ABI may come from C, but it's not limited to C. Many other languages have FFI and use the C ABI as the lowest common denominator. But the C ABI is awful to work with. The C language itself offers no help to guarantee ABI compatibility. What ABI it compiles for depends on headers, which may depend on a jungle of ifdefs and typedefs.

rwmj 6y ago

An advantage of Rust and Golang (and OCaml actually[1]) is they let you write to the C ABI. We've written both components that call into existing C ABI (nbdkit-{rust|golang}-plugin), and also Rust/Golang/OCaml shared libraries that present C ABI functions / structures to the world. [1] But you need to write a bit of C glue code for OCaml so it's not quite so seamless.

bachmeier 6y ago
And D. It works so well that the compiler has betterC mode: https://dlang.org/spec/betterc.html https://dlang.org/spec/betterc.html
int_19h 6y ago
Some form of C FFI has been standard for most languages that appeared after C became ubiquitous. Even something as dynamic and high-level as Python has ctypes.

sigjuice 6y ago

What standard ABI? If I look at the gcc man page, there is a large number of abi related knobs.