5 ms·

Why stick with c89? Can't think of any compilers that doesn't support c99 nowadays. The major benefit is that you can use uint8_t and friends directly and don't

Why stick with c89? Can't think of any compilers that doesn't support c99 nowadays. The major benefit is that you can use uint8_t and friends directly and don't need to define your own wrapper types.

boricj 3y ago
Funnily enough, the file rv.h does use stdint.h if available and contains the following comment: > All I want for Christmas is C89 with stdint.h
mnurzia 3y ago
It's more of a fun exercise, I guess. But I do have experience with at least one compiler that doesn't support C99: Zilog's ez80 C compiler. Back in the day I used to program my TI-84+ CE for fun[0], and the only C solution was a pretty bespoke C89-only compiler[1] distributed with a community toolchain[2], which has since switched to clang. It's somewhat irrational, but in the back of my mind it bugs me if the software I write can't run on platforms like that. [0] https://github.com/mnurzia/chip8-ce https://github.com/mnurzia/chip8-ce [1] http://www.zilog.com/docs/appnotes/pb0098.pdf http://www.zilog.com/docs/appnotes/pb0098.pdf [2] https://ce-programming.github.io/toolchain/ https://ce-programming.github.io/toolchain/
contrarian1234 3y ago
Did Visual Studio finally make the jump?! (you could always just compile it as C++ code though)
- bjourne 3y ago
  Nope stdint.h has been in msvc for over 10 years. Other c99 features may be not supported though.
  - jpfr 3y ago
    MSVC did a big rewrite of the C frontend around MSVC2013. I haven’t encountered C99 idioms that don’t work nowadays. Granted, I might not use every feature in my typical coding style…
    - arp242 3y ago
      It's been "fully" C99 (and C11, C17) compliant for about 2 or 3 years. The only missing C99 featured before that were relatively rarely used ones like _Pragma.
      - flohofwoe 3y ago
        It's not C99 compliant because that would require VLA support (which has been made optional in C11, which in turn enabled MSVC to be a C11 and C17 compiler, but not C99. Not that it matters much in practice though :)
  - mort96 3y ago
    Hasn't the main issue with MS been VLAs? I seem to recall that VLAs are the main reason MSVC won't ever support C99, and that MSVC is one of the main reasons why VLAs were made optional. It seems like MSVC supports C11 and C17 now, thanks to the removal of mandatory VLAs.
    - zabzonk 3y ago
      vehement oppostion from ms my be one of the reasons for them being optional (and thus worthless) but the main one is that that they are impossible to use correctly. what happens if you make one too big?
      - mort96 3y ago
        I think they could potentially have some very limited valid use cases, but I agree that a fixed length array and/or heap allocation is usually much better than VLAs. I was mainly just pointing out that MS's lack of C99 support isn't really a part of keeping C89 alive, especially now that they officially support C11.
        aragilar 3y ago
        I'm not sure how robust that support is though: https://discuss.python.org/t/requiring-compilers-c11-standard-mode-to-build-cpython/26481/23 https://discuss.python.org/t/requiring-compilers-c11-standar...
        mort96 3y ago
        If the reply is correct, the only issue there is that they're compiling in C89 mode. If you pass `-pedantic -std=c89` to GCC, it too will warn on C99+ features. If you pass `/std:c11` or `/std:c17` to MSVC, C99+ features should work.
      - Dylan16807 3y ago
        > what happens if you make one too big? Doesn't that apply to fixed length arrays too?
  - flohofwoe 3y ago
    Except for VLAs (which are optional post-C99 anyway), MSVC actually has pretty good support for recent C versions, and since 2020 they're basically back on the "modern C" train: https://devblogs.microsoft.com/cppblog/c11-and-c17-standard-support-arriving-in-msvc/ https://devblogs.microsoft.com/cppblog/c11-and-c17-standard-...
dezgeg 3y ago
I've met several people that seriously think that C89 is the peak of programming languages and that C99 just brings misfeatures (like, allowing variable declarations in middle of basic blocks according to them)
- foobarbaz33 3y ago
  Forcing declares at the top makes it easy to estimate at a glance (or exactly calculate) how much space the stack frame will use.
  - dezgeg 3y ago
    Maybe in the early days of C, but with modern compilers doing stuff like keeping variables in only registers, inlining functions, stack cookies, merging non overlapping variables etc. that seems not really worth it. If you want to avoid accidental huge stack usage you can pass flag to gcc/clang to trigger warning when stack usage of a function goes over the specified limit.
flohofwoe 3y ago
One "advantage" (if one wants to call that) is that the code would also compile as C++, while C99 has diverged enough from the common C/C++ subset that one cannot use all C99 features in C++ mode.
- mnurzia 3y ago
  I totally missed this, good point. Slightly unrelated, but just thought I should mention: the sokol libraries are awesome!
- bjourne 3y ago
  There never was a "common C/C++ subset". See https://softwareengineering.stackexchange.com/a/298667/18260 https://softwareengineering.stackexchange.com/a/298667/18260
  - flohofwoe 3y ago
    Ah that old thing again ;) C isn't a subset of C++ (and never was). But there's still a common subset of both the C and C++ languages which compiles both in a C compiler and a C++ compiler (and behaves the same at runtime despite slightly different C vs C++ semantics), and that common subset is what I call C/C++: the pidgin dialect that's neither quite C nor quite C++ but compiles as both.

Why stick with c89? Can't think of any compilers that doesn't support c99 nowadays. The major benefit is that you can use uint8_t and friends directly and don't need to define your own wrapper types.

boricj 3y ago

Funnily enough, the file rv.h does use stdint.h if available and contains the following comment: > All I want for Christmas is C89 with stdint.h

mnurzia 3y ago

It's more of a fun exercise, I guess. But I do have experience with at least one compiler that doesn't support C99: Zilog's ez80 C compiler. Back in the day I used to program my TI-84+ CE for fun[0], and the only C solution was a pretty bespoke C89-only compiler[1] distributed with a community toolchain[2], which has since switched to clang. It's somewhat irrational, but in the back of my mind it bugs me if the software I write can't run on platforms like that. [0] https://github.com/mnurzia/chip8-ce https://github.com/mnurzia/chip8-ce [1] http://www.zilog.com/docs/appnotes/pb0098.pdf http://www.zilog.com/docs/appnotes/pb0098.pdf [2] https://ce-programming.github.io/toolchain/ https://ce-programming.github.io/toolchain/

contrarian1234 3y ago

Did Visual Studio finally make the jump?! (you could always just compile it as C++ code though)

bjourne 3y ago
Nope stdint.h has been in msvc for over 10 years. Other c99 features may be not supported though.
- jpfr 3y ago
  MSVC did a big rewrite of the C frontend around MSVC2013. I haven’t encountered C99 idioms that don’t work nowadays. Granted, I might not use every feature in my typical coding style…
  - arp242 3y ago
    It's been "fully" C99 (and C11, C17) compliant for about 2 or 3 years. The only missing C99 featured before that were relatively rarely used ones like _Pragma.
    - flohofwoe 3y ago
      It's not C99 compliant because that would require VLA support (which has been made optional in C11, which in turn enabled MSVC to be a C11 and C17 compiler, but not C99. Not that it matters much in practice though :)
- mort96 3y ago
  Hasn't the main issue with MS been VLAs? I seem to recall that VLAs are the main reason MSVC won't ever support C99, and that MSVC is one of the main reasons why VLAs were made optional. It seems like MSVC supports C11 and C17 now, thanks to the removal of mandatory VLAs.
  - zabzonk 3y ago
    vehement oppostion from ms my be one of the reasons for them being optional (and thus worthless) but the main one is that that they are impossible to use correctly. what happens if you make one too big?
    - mort96 3y ago
      I think they could potentially have some very limited valid use cases, but I agree that a fixed length array and/or heap allocation is usually much better than VLAs. I was mainly just pointing out that MS's lack of C99 support isn't really a part of keeping C89 alive, especially now that they officially support C11.
      - aragilar 3y ago
        I'm not sure how robust that support is though: https://discuss.python.org/t/requiring-compilers-c11-standard-mode-to-build-cpython/26481/23 https://discuss.python.org/t/requiring-compilers-c11-standar...
        mort96 3y ago
        If the reply is correct, the only issue there is that they're compiling in C89 mode. If you pass `-pedantic -std=c89` to GCC, it too will warn on C99+ features. If you pass `/std:c11` or `/std:c17` to MSVC, C99+ features should work.
    - Dylan16807 3y ago
      > what happens if you make one too big? Doesn't that apply to fixed length arrays too?
- flohofwoe 3y ago
  Except for VLAs (which are optional post-C99 anyway), MSVC actually has pretty good support for recent C versions, and since 2020 they're basically back on the "modern C" train: https://devblogs.microsoft.com/cppblog/c11-and-c17-standard-support-arriving-in-msvc/ https://devblogs.microsoft.com/cppblog/c11-and-c17-standard-...

dezgeg 3y ago

I've met several people that seriously think that C89 is the peak of programming languages and that C99 just brings misfeatures (like, allowing variable declarations in middle of basic blocks according to them)

foobarbaz33 3y ago
Forcing declares at the top makes it easy to estimate at a glance (or exactly calculate) how much space the stack frame will use.
- dezgeg 3y ago
  Maybe in the early days of C, but with modern compilers doing stuff like keeping variables in only registers, inlining functions, stack cookies, merging non overlapping variables etc. that seems not really worth it. If you want to avoid accidental huge stack usage you can pass flag to gcc/clang to trigger warning when stack usage of a function goes over the specified limit.

flohofwoe 3y ago

One "advantage" (if one wants to call that) is that the code would also compile as C++, while C99 has diverged enough from the common C/C++ subset that one cannot use all C99 features in C++ mode.

mnurzia 3y ago
I totally missed this, good point. Slightly unrelated, but just thought I should mention: the sokol libraries are awesome!
bjourne 3y ago
There never was a "common C/C++ subset". See https://softwareengineering.stackexchange.com/a/298667/18260 https://softwareengineering.stackexchange.com/a/298667/18260
- flohofwoe 3y ago
  Ah that old thing again ;) C isn't a subset of C++ (and never was). But there's still a common subset of both the C and C++ languages which compiles both in a C compiler and a C++ compiler (and behaves the same at runtime despite slightly different C vs C++ semantics), and that common subset is what I call C/C++: the pidgin dialect that's neither quite C nor quite C++ but compiles as both.