7 ms·

Many people still write in a C89 dialect just fine. Most of the good stuff is written in it: sqlite, curl, STB libraries, zlib, OS kernels etc.

by pmarin 3y ago

jmclnx 3y ago
Yes, that is what I stick to also, and that is better for portability.
sylware 3y ago
C syntax is already too rich and complex. What it needs is not more but less and some fixing: Only sized primitive types (u8/s8...u64/s64, f32/f64); typedef, enum, switch, all but one loop keyword (loop{}) should go away; No more integer promotion, only compile-time/runtime explicit casts (except for literals, and maybe void * pointers); explicit compile-time constants; no anonymous code block; etc. That said, if risc-v is successful, many components will be written directly in assembly, and trash-abl code will be written in very high-level languages with risc-v assembly written interpreters (python/perl5/lua/javascript/ruby/php/haskell/tintin/milou).
- klodolph 3y ago
  The variable-size int, unfortunately, made a lot of sense in the early days of C. On processors like the x86 and 68000, it made sense for int to be 16-bit, so you don't pay for the bits you don't need. On newer systems, it makes sense for int to be 32-bit, so you don't pay to throw away bits.
  - sylware 3y ago
    That's why it needs fixing. We are not in the early days anymore.
    - klodolph 3y ago
      Problem is simple—there are still systems out there like that, and people are still buying them and writing C code for them. They're just in the embedded space, where day-to-day programmers don't encounter them.
      - sylware 3y ago
        Then those systems are maintained, then then could correct their legacy C code to "fixed-C" (which should be not that much in-real-life anyways). It would be possible to do a quick-and-dirty work with preprocessor definitions. The real thing is when you want to write "fixed-C" with a legacy compiler: you realize than it does so much things without telling you, you would need a really accurate warning system in order to catch all those things. I was told gcc can report all integer promotions, true?
    - astrange 3y ago
      You shouldn't fix it by making users choose what bit width their ints are. That's not the right answer for performance (they don't know what's fastest) or correctness (the only choices are incorrect). If you have a variable whose values are 0-10, then its type is an integer that goes from 0-10, not from 0-255 or -127-127.
  - KMag 3y ago
    The variable-sized word made more sense when writing code to work acoss machines with 16-bit and 18-bit words or 32-bit and 36-bit words. This is also why you get C99's uint_least32_t and friends, so you're not accidentally forcing a 36-bit machine to have 32-bit overflow behavior everywhere. Before the mid-late 1990s, programmers rarely needed to worry about the difference in size between 32 and 36 bit words.
- kps 3y ago
  > Only sized primitive types (u8/s8...u64/s64, f32/f64); C's success came from portability, so that would have killed it. Certainly you need fixed-size types occasionally to match externally-defined structures (hardware, protocols) but if you write u8 loop counters and u32 accumulators you're screwed on a DSP with only u24. > That said, if risc-v is successful, many components will be written directly in assembly There are already too many RISC-V extensions for code to be portable between different RISC-V chips without using a higher-level language.
  - colejohnson66 3y ago
    > Certainly you need fixed-size types occasionally to match externally-defined structures (hardware, protocols) but if you write u8 loop counters and u32 accumulators you're screwed on a DSP with only u24. This "portability" argument always rings hollow. How often are you actually reusing code between a DSP and a desktop? When real sizes don't matter, but just a minimum range, there's `(u)int_least8_t` (could be renamed as `u_min8`). On a DSP with only, say, 16-bit "bytes" (like the TMS320), that would internally be a `u16`. C is not a "portable assembler" anymore. That's a myth. Almost no one writes C in a portable way. Every library or program has their on version of <stdint.h>. glibc, for example, uses gu8 for `unsigned char`. Put that on your 24-bit DSP, and `gu8` just became the same as `gu16` and the nonexistent `gu24`. C is a language designed around a PDP/11 and inherits that legacy baggage. The C committee that refuses to accept the reality for "purity" reasons holds back the language.
    - sylware 3y ago
      Yep, that's why you would have had a "fixed-C" compiler with an explicit u24 and "portability", if it has any meaning here, would have to be done at the user program level. The C committee is just adding stuff, to make even a naive C compiler more and more costly, which kills many "real life" alternatives, and in the end, does promote planned obsolescence more than anything else. We have to remove stuff from C, not add stuff to C, make things more explicit and not more implicit (the abomination of the integer promotion...). The stdlib has nothing to do in the C syntax even though not having memcpy and co internal to the compiler feels really meh on modern CPU.
tlamponi 3y ago
> OS kernels Many are, but Linux moved to C11 (well gnu11 I guess) since v5.18 Summary of discussion: https://lwn.net/Articles/885941/ https://lwn.net/Articles/885941/ Actual move https://git.kernel.org/linus/e8c07082a810fbb9db303a2b66b66b8d7e588b53 https://git.kernel.org/linus/e8c07082a810fbb9db303a2b66b66b8... Being able to replace int i; for (i = 0; i < foo; i++) { ... } with for (int i = 0; i < foo; i++) { ... } makes it already worthwhile. Linus thinks so too: > I think the loop iterators are the biggest user-visible thing, but > there might be others. Also interesting: > Of course, the C standard being the bunch of incompetents they are, > they in the process apparently made left-shifts undefined (rather than > implementation-defined). Christ, they keep on making the same mistakes > over and over. What was the definition of insanity again? -- https://lwn.net/ml/linux-kernel/CAHk-=wicJ0VxEmnpb8=TJfkSDytFuf+dvQJj8kFWj0OF2FBZ9w@mail.gmail.com/ https://lwn.net/ml/linux-kernel/CAHk-=wicJ0VxEmnpb8=TJfkSDyt...
- astrange 3y ago
  > Also interesting: The issues here are: - if it's defined, then people will rely on it, which means UBSan can't report it as an error if it sees it. - IIRC x86 defines the overflow behavior differently for scalar and vector ints, so x86 compilers that want to do autovectorization would probably leave it undefined. C's original sin here is that the numeric promotion rules are wrong ('unsigned short' should not promote to 'int'!) but as long as you can't fix that, you can't get rid of UB and still be performant.
  - uecker 3y ago
    What is wrong with promoting unsigned short to int?

Many people still write in a C89 dialect just fine. Most of the good stuff is written in it: sqlite, curl, STB libraries, zlib, OS kernels etc.

by pmarin 3y ago

Many people still write in a C89 dialect just fine. Most of the good stuff is written in it: sqlite, curl, STB libraries, zlib, OS kernels etc.

jmclnx 3y ago

Yes, that is what I stick to also, and that is better for portability.

sylware 3y ago

C syntax is already too rich and complex. What it needs is not more but less and some fixing: Only sized primitive types (u8/s8...u64/s64, f32/f64); typedef, enum, switch, all but one loop keyword (loop{}) should go away; No more integer promotion, only compile-time/runtime explicit casts (except for literals, and maybe void * pointers); explicit compile-time constants; no anonymous code block; etc. That said, if risc-v is successful, many components will be written directly in assembly, and trash-abl code will be written in very high-level languages with risc-v assembly written interpreters (python/perl5/lua/javascript/ruby/php/haskell/tintin/milou).

klodolph 3y ago
The variable-size int, unfortunately, made a lot of sense in the early days of C. On processors like the x86 and 68000, it made sense for int to be 16-bit, so you don't pay for the bits you don't need. On newer systems, it makes sense for int to be 32-bit, so you don't pay to throw away bits.
- sylware 3y ago
  That's why it needs fixing. We are not in the early days anymore.
  - klodolph 3y ago
    Problem is simple—there are still systems out there like that, and people are still buying them and writing C code for them. They're just in the embedded space, where day-to-day programmers don't encounter them.
    - sylware 3y ago
      Then those systems are maintained, then then could correct their legacy C code to "fixed-C" (which should be not that much in-real-life anyways). It would be possible to do a quick-and-dirty work with preprocessor definitions. The real thing is when you want to write "fixed-C" with a legacy compiler: you realize than it does so much things without telling you, you would need a really accurate warning system in order to catch all those things. I was told gcc can report all integer promotions, true?
  - astrange 3y ago
    You shouldn't fix it by making users choose what bit width their ints are. That's not the right answer for performance (they don't know what's fastest) or correctness (the only choices are incorrect). If you have a variable whose values are 0-10, then its type is an integer that goes from 0-10, not from 0-255 or -127-127.
- KMag 3y ago
  The variable-sized word made more sense when writing code to work acoss machines with 16-bit and 18-bit words or 32-bit and 36-bit words. This is also why you get C99's uint_least32_t and friends, so you're not accidentally forcing a 36-bit machine to have 32-bit overflow behavior everywhere. Before the mid-late 1990s, programmers rarely needed to worry about the difference in size between 32 and 36 bit words.
kps 3y ago
> Only sized primitive types (u8/s8...u64/s64, f32/f64); C's success came from portability, so that would have killed it. Certainly you need fixed-size types occasionally to match externally-defined structures (hardware, protocols) but if you write u8 loop counters and u32 accumulators you're screwed on a DSP with only u24. > That said, if risc-v is successful, many components will be written directly in assembly There are already too many RISC-V extensions for code to be portable between different RISC-V chips without using a higher-level language.
- colejohnson66 3y ago
  > Certainly you need fixed-size types occasionally to match externally-defined structures (hardware, protocols) but if you write u8 loop counters and u32 accumulators you're screwed on a DSP with only u24. This "portability" argument always rings hollow. How often are you actually reusing code between a DSP and a desktop? When real sizes don't matter, but just a minimum range, there's `(u)int_least8_t` (could be renamed as `u_min8`). On a DSP with only, say, 16-bit "bytes" (like the TMS320), that would internally be a `u16`. C is not a "portable assembler" anymore. That's a myth. Almost no one writes C in a portable way. Every library or program has their on version of <stdint.h>. glibc, for example, uses gu8 for `unsigned char`. Put that on your 24-bit DSP, and `gu8` just became the same as `gu16` and the nonexistent `gu24`. C is a language designed around a PDP/11 and inherits that legacy baggage. The C committee that refuses to accept the reality for "purity" reasons holds back the language.
  - sylware 3y ago
    Yep, that's why you would have had a "fixed-C" compiler with an explicit u24 and "portability", if it has any meaning here, would have to be done at the user program level. The C committee is just adding stuff, to make even a naive C compiler more and more costly, which kills many "real life" alternatives, and in the end, does promote planned obsolescence more than anything else. We have to remove stuff from C, not add stuff to C, make things more explicit and not more implicit (the abomination of the integer promotion...). The stdlib has nothing to do in the C syntax even though not having memcpy and co internal to the compiler feels really meh on modern CPU.

tlamponi 3y ago

> OS kernels Many are, but Linux moved to C11 (well gnu11 I guess) since v5.18 Summary of discussion: https://lwn.net/Articles/885941/ https://lwn.net/Articles/885941/ Actual move https://git.kernel.org/linus/e8c07082a810fbb9db303a2b66b66b8d7e588b53 https://git.kernel.org/linus/e8c07082a810fbb9db303a2b66b66b8... Being able to replace int i; for (i = 0; i < foo; i++) { ... } with for (int i = 0; i < foo; i++) { ... } makes it already worthwhile. Linus thinks so too: > I think the loop iterators are the biggest user-visible thing, but > there might be others. Also interesting: > Of course, the C standard being the bunch of incompetents they are, > they in the process apparently made left-shifts undefined (rather than > implementation-defined). Christ, they keep on making the same mistakes > over and over. What was the definition of insanity again? -- https://lwn.net/ml/linux-kernel/CAHk-=wicJ0VxEmnpb8=TJfkSDytFuf+dvQJj8kFWj0OF2FBZ9w@mail.gmail.com/ https://lwn.net/ml/linux-kernel/CAHk-=wicJ0VxEmnpb8=TJfkSDyt...

astrange 3y ago
> Also interesting: The issues here are: - if it's defined, then people will rely on it, which means UBSan can't report it as an error if it sees it. - IIRC x86 defines the overflow behavior differently for scalar and vector ints, so x86 compilers that want to do autovectorization would probably leave it undefined. C's original sin here is that the numeric promotion rules are wrong ('unsigned short' should not promote to 'int'!) but as long as you can't fix that, you can't get rid of UB and still be performant.
- uecker 3y ago
  What is wrong with promoting unsigned short to int?