6 ms·

The author is not talking about C but about the C ABI that is the default OS ABI. It's an ABI, there have to be one, and C was the de-facto system programming

The author is not talking about C but about the C ABI that is the default OS ABI. It's an ABI, there have to be one, and C was the de-facto system programming language. I don't get the complaint, there are flaws, it could have been much MUCH worse.

wvenable 4y ago
The complaint is that C isn't the only systems language anymore so defining the ABI in terms of executable C code is a pain-in-the-ass for those other languages. C is also a terrible language to define an ABI because, by design, it's very imprecise in the way that it defines types.
- AnIdiotOnTheNet 4y ago
  > The complaint is that C isn't the only systems language anymore C was never the only systems language.
  - pjmlp 4y ago
    For a long time on UNIX it definitely was, until it got its sibling CFront in the package.
- akira2501 4y ago
  > it's very imprecise in the way that it defines types. It's perfectly precise, particularly if you choose to use <stdint.h> which has been available in the language for a very long time. You may have some issues with specific types and platform variability, but it's absurd to cast this as "it's imprecise with types." It's _flexible_ with types. People seem to miss that this is the reason why C is the lingua franca. It isn't trying to "perfect" computing. It just makes it possible. There's a lesson for new languages here.
- unclad5968 4y ago
  What kind of precision would you like to see added to the way C defines types?
  - saagarjha 4y ago
    It would be nice if you could just look at an interface and know it returns a 32-bit integer without parsing four C headers to get that information.
    - bayindirh 4y ago
      C's variables always scale to use the underlying hardware in the most efficient way in terms of performance. There's always sizeof() and macros to get the size of the variables you have. This is why C is mostly portable with minimum effort unless you do hardware specific things, or use the variable to their limits. In that case you can always define fixed size types. I don't get why people love to bash C. No language has an obligation to do please the programmer in its default modus operandi. Programming languages exist to interface hardware with humans, and C operates in the realm of the hardware, and that's perfectly OK for me.
      - saagarjha 4y ago
        No they don’t. If we cared about that we’d be using ILP64 instead of keeping int at 32 bits for compatibility reasons. I’m not here to bash C, anyhow; I think you’re failing to consider that I have experience with C and what it’s not good at, and am able to look past trite statements like “C interfaces with the hardware” that aren’t true or useful. In this case the concern is that C doesn’t make it convenient to talk to hardware!
      - pornel 4y ago
        That is the pitch, but not the reality. C ABIs (of which there are many because the C standard doesn’t cover ABI) are full of legacy cruft, because they need to be stable and backwards-compatible more than they need to be sensible or efficient. The C ABI can even vary depending on compiler flags, e.g. availability of AVX affects calling conventions. It’s not easy to be interoperable with this, especially when ABI-affecting compiler flags and macros may be set by an arbitrary build system, not even the C source code.
lowbloodsugar 4y ago
I think if it was any worse, it (Linux, BSD, etc) wouldn’t function at all. So it is maximally worse for the subset of things that function. It’s like getting all the worst medical conditions that don’t actually kill you. Sure, there are worse diseases: you could be dead. Is that any comfort? Probably not. Probably be looking for a cure.
pjmlp 4y ago
C is only the OS ABI in operating systems written in C.
- marcosdumay 4y ago
  Even if you go into niche OSes and find one not written in C, I doubt what you said will be correct.
  - pjmlp 4y ago
    You can start by learning about IBM and Unisys mainframes and microcomputers. Then dive into Vax/VMS with Bliss, Multics with PL/I and plenty of others that lost to UNIX.
    - cestith 4y ago
      Oberon one could guess by seeing it's an OS and its implementation language, tightly coupled under the same name, that Oberon's ABI uses Oberon. Loosely defined, most embedded Forth systems act as an OS and they tend to use the system's assembly or the Forth system itself as the ABI. PC-DOS derivatives obviously use x86 registers and interrupts as an ABI - that's more assembly and machine language oriented than C.
- cryptonector 4y ago
  Which is all the ones that matter the most for this discussion due to market share / mindshare.
  - pjmlp 4y ago
    Good luck using the C ABI on ChromeOS or Android.
    - saagarjha 4y ago
      Android is Linux-based and has many of the same problems. Chrome OS too if you’re writing to the metal.
sim7c00 4y ago
agreed, much of the bickering is on ABIs and FFI stuff which you could argue is hard due to ABI differences it supports. this is not a C problem, but a complexity C exposes. C does do that a lot, but thats also a strength. There are really no sound alternatives to C for low level system programming (OS core functionality, or embedded stuff). there's C++ ofcourse but regarding the complaints it suffers the same. Rust doesnt solve anything there, its impossible still to actually build a modern OS in rust for example. (maybe if most your core is wrapped in unsafe and you run on only a single core device...). If C is such a problem id like to see some alternatives which offer what C does but less painfully. C is only useful in certain domains, but within the domains where C is really good, theres no others. (unless you want to go assembly mode... good luck :) can be fun).. anyhting that is less painful, exposes less complexity and is usually therefore less generally applicable. A lot of the pains of C are lack of understanding how to use it because using it requires deep knowledge of it, and the target platform. that being said, i do get userland applications and C dont really mix anymore. that is a fair point imho.
deleted 4y ago
[deleted]
simplotek 4y ago
> I don't get the complaint, there are flaws, it could have been much MUCH worse. I find it amusing that after half a century of existence and powering the world's IT infrastructure, suddenly some illuminated individual felt entitled to claim they alone found problems that they alone can fix.
layer8 4y ago
There isn’t the C ABI, as the article actually mentions. There are various ABIs, most of which (but not necessarily all) can be targeted by a combination of C declarations and compiler switches. The one thing that could be improved is to come up with a better language than C headers to specify cross-language APIs/ABIs. The fact that different ABIs exist cannot be helped. That’s something one has to cope with in any case, independently of C. One way to sidestep many of the issues is to target the JVM. ;)
kmacdough 4y ago
It could be worse, but for the long-term evolution of computing, we should be working towards convergent systems. There's enough subtlety and imprecision in the C spec that it's not well suited to convergence. Among type issues, it also has the infamous "Macros" that are really just unanalyzable text replacements.

wvenable 4y ago

The complaint is that C isn't the only systems language anymore so defining the ABI in terms of executable C code is a pain-in-the-ass for those other languages. C is also a terrible language to define an ABI because, by design, it's very imprecise in the way that it defines types.

AnIdiotOnTheNet 4y ago
> The complaint is that C isn't the only systems language anymore C was never the only systems language.
- pjmlp 4y ago
  For a long time on UNIX it definitely was, until it got its sibling CFront in the package.
akira2501 4y ago
> it's very imprecise in the way that it defines types. It's perfectly precise, particularly if you choose to use <stdint.h> which has been available in the language for a very long time. You may have some issues with specific types and platform variability, but it's absurd to cast this as "it's imprecise with types." It's _flexible_ with types. People seem to miss that this is the reason why C is the lingua franca. It isn't trying to "perfect" computing. It just makes it possible. There's a lesson for new languages here.
unclad5968 4y ago
What kind of precision would you like to see added to the way C defines types?
- saagarjha 4y ago
  It would be nice if you could just look at an interface and know it returns a 32-bit integer without parsing four C headers to get that information.
  - bayindirh 4y ago
    C's variables always scale to use the underlying hardware in the most efficient way in terms of performance. There's always sizeof() and macros to get the size of the variables you have. This is why C is mostly portable with minimum effort unless you do hardware specific things, or use the variable to their limits. In that case you can always define fixed size types. I don't get why people love to bash C. No language has an obligation to do please the programmer in its default modus operandi. Programming languages exist to interface hardware with humans, and C operates in the realm of the hardware, and that's perfectly OK for me.
    - saagarjha 4y ago
      No they don’t. If we cared about that we’d be using ILP64 instead of keeping int at 32 bits for compatibility reasons. I’m not here to bash C, anyhow; I think you’re failing to consider that I have experience with C and what it’s not good at, and am able to look past trite statements like “C interfaces with the hardware” that aren’t true or useful. In this case the concern is that C doesn’t make it convenient to talk to hardware!
    - pornel 4y ago
      That is the pitch, but not the reality. C ABIs (of which there are many because the C standard doesn’t cover ABI) are full of legacy cruft, because they need to be stable and backwards-compatible more than they need to be sensible or efficient. The C ABI can even vary depending on compiler flags, e.g. availability of AVX affects calling conventions. It’s not easy to be interoperable with this, especially when ABI-affecting compiler flags and macros may be set by an arbitrary build system, not even the C source code.

lowbloodsugar 4y ago

I think if it was any worse, it (Linux, BSD, etc) wouldn’t function at all. So it is maximally worse for the subset of things that function. It’s like getting all the worst medical conditions that don’t actually kill you. Sure, there are worse diseases: you could be dead. Is that any comfort? Probably not. Probably be looking for a cure.

pjmlp 4y ago

C is only the OS ABI in operating systems written in C.

marcosdumay 4y ago
Even if you go into niche OSes and find one not written in C, I doubt what you said will be correct.
- pjmlp 4y ago
  You can start by learning about IBM and Unisys mainframes and microcomputers. Then dive into Vax/VMS with Bliss, Multics with PL/I and plenty of others that lost to UNIX.
  - cestith 4y ago
    Oberon one could guess by seeing it's an OS and its implementation language, tightly coupled under the same name, that Oberon's ABI uses Oberon. Loosely defined, most embedded Forth systems act as an OS and they tend to use the system's assembly or the Forth system itself as the ABI. PC-DOS derivatives obviously use x86 registers and interrupts as an ABI - that's more assembly and machine language oriented than C.
cryptonector 4y ago
Which is all the ones that matter the most for this discussion due to market share / mindshare.
- pjmlp 4y ago
  Good luck using the C ABI on ChromeOS or Android.
  - saagarjha 4y ago
    Android is Linux-based and has many of the same problems. Chrome OS too if you’re writing to the metal.

sim7c00 4y ago

agreed, much of the bickering is on ABIs and FFI stuff which you could argue is hard due to ABI differences it supports. this is not a C problem, but a complexity C exposes. C does do that a lot, but thats also a strength. There are really no sound alternatives to C for low level system programming (OS core functionality, or embedded stuff). there's C++ ofcourse but regarding the complaints it suffers the same. Rust doesnt solve anything there, its impossible still to actually build a modern OS in rust for example. (maybe if most your core is wrapped in unsafe and you run on only a single core device...). If C is such a problem id like to see some alternatives which offer what C does but less painfully. C is only useful in certain domains, but within the domains where C is really good, theres no others. (unless you want to go assembly mode... good luck :) can be fun).. anyhting that is less painful, exposes less complexity and is usually therefore less generally applicable. A lot of the pains of C are lack of understanding how to use it because using it requires deep knowledge of it, and the target platform. that being said, i do get userland applications and C dont really mix anymore. that is a fair point imho.

deleted 4y ago

[deleted]

simplotek 4y ago

> I don't get the complaint, there are flaws, it could have been much MUCH worse. I find it amusing that after half a century of existence and powering the world's IT infrastructure, suddenly some illuminated individual felt entitled to claim they alone found problems that they alone can fix.

layer8 4y ago

There isn’t the C ABI, as the article actually mentions. There are various ABIs, most of which (but not necessarily all) can be targeted by a combination of C declarations and compiler switches. The one thing that could be improved is to come up with a better language than C headers to specify cross-language APIs/ABIs. The fact that different ABIs exist cannot be helped. That’s something one has to cope with in any case, independently of C. One way to sidestep many of the issues is to target the JVM. ;)

kmacdough 4y ago

It could be worse, but for the long-term evolution of computing, we should be working towards convergent systems. There's enough subtlety and imprecision in the C spec that it's not well suited to convergence. Among type issues, it also has the infamous "Macros" that are really just unanalyzable text replacements.