6 ms·

definitely a good idea. will add that to the “todo” list

by mcpcpc 6y ago

snvzz 6y ago
To the contrary, I wouldn't. Using C99 + POSIX is the defining fact about your project. I would let somebody else write a C89 irc client, instead.
- flohofwoe 6y ago
  Agreed, also "retro system compiler" doesn't mean it only supports old C standards, e.g. SDCC is C99 and C11 compatible. IMHO strict C89 is a much less enjoyable language to read and write than C99, for instance designated initialization and compound literals are massive improvements. Also MSVC's C99 support is pretty good since ca. VS2015.
  - snvzz 6y ago
    I was similarly thinking vbcc.
  - cogburnd02 6y ago
    cc65 ( https://github.com/cc65/cc65 https://github.com/cc65/cc65 ) doesn't do C99 "and never will" according to https://cc65.github.io/doc/cc65.html https://cc65.github.io/doc/cc65.html but it's probably the most developed C compiler for 6502-based systems.
    - snvzz 6y ago
      That's a shame.
  - CyberRabbi 6y ago
    When I mentioned retro systems, I had in mind obsolete compilers in stock installations of IRIX, AIX, Solaris, BeOS, NextStep, Amiga Unix etc. Not modern compilers that target 8-bit microcontrollers like SDCC.
  - pjmlp 6y ago
    To the extent required by ISO C++ compliance, although they just announced at CppCon that C11 and C17 are getting full support. Naturally like everyone else in the C world, with exception of gcc/clang, all C99 features that became optional in C11 aren't planned to be supported.
    - flohofwoe 6y ago
      The MSVC C compiler supported the full C99 designated initialization and compound literal features in VS2015, both are not part of the common C/C++ subset, but exclusive C99 features. So all in all the C99 support in MSVC hasn't been that bad since ca 2015, it just wasn't complete enough to be called "standard C99". But yeah, those C99 features weren't consistent at all with Herb Sutter's 2012 blog post about MSVC only supporting C features that are needed for the C++ compiler. C and C++ are more strictly separated in the Microsoft compilers compared to gcc and clang (which both support more modern C features in C++ mode via non-standard extensions), I think that's what's confusing many people. It's not a problem in mixed-language projects though, just put all the C code into .c files and all C++ code into .cpp and you're set, compiling C code with a C++ compiler isn't such a great idea anyway, since it limits you to a ca. 1995 version of C.
- petre 6y ago
  Why not write it in betterC? https://dlang.org/spec/betterc.html https://dlang.org/spec/betterc.html
  - flohofwoe 6y ago
    Because despite the name this "betterC" is not a C dialect, but a D dialect which is an entirely different language than C99? Could just as well ask why not write it in Nim, Zig, Rust, Swift, Kotlin etc... This means a different audience, different target platforms, different trade-offs.

definitely a good idea. will add that to the “todo” list

by mcpcpc 6y ago

definitely a good idea. will add that to the “todo” list

To the contrary, I wouldn't. Using C99 + POSIX is the defining fact about your project. I would let somebody else write a C89 irc client, instead.

flohofwoe 6y ago
Agreed, also "retro system compiler" doesn't mean it only supports old C standards, e.g. SDCC is C99 and C11 compatible. IMHO strict C89 is a much less enjoyable language to read and write than C99, for instance designated initialization and compound literals are massive improvements. Also MSVC's C99 support is pretty good since ca. VS2015.
- snvzz 6y ago
  I was similarly thinking vbcc.
- cogburnd02 6y ago
  cc65 ( https://github.com/cc65/cc65 https://github.com/cc65/cc65 ) doesn't do C99 "and never will" according to https://cc65.github.io/doc/cc65.html https://cc65.github.io/doc/cc65.html but it's probably the most developed C compiler for 6502-based systems.
  - snvzz 6y ago
    That's a shame.
- CyberRabbi 6y ago
  When I mentioned retro systems, I had in mind obsolete compilers in stock installations of IRIX, AIX, Solaris, BeOS, NextStep, Amiga Unix etc. Not modern compilers that target 8-bit microcontrollers like SDCC.
- pjmlp 6y ago
  To the extent required by ISO C++ compliance, although they just announced at CppCon that C11 and C17 are getting full support. Naturally like everyone else in the C world, with exception of gcc/clang, all C99 features that became optional in C11 aren't planned to be supported.
  - flohofwoe 6y ago
    The MSVC C compiler supported the full C99 designated initialization and compound literal features in VS2015, both are not part of the common C/C++ subset, but exclusive C99 features. So all in all the C99 support in MSVC hasn't been that bad since ca 2015, it just wasn't complete enough to be called "standard C99". But yeah, those C99 features weren't consistent at all with Herb Sutter's 2012 blog post about MSVC only supporting C features that are needed for the C++ compiler. C and C++ are more strictly separated in the Microsoft compilers compared to gcc and clang (which both support more modern C features in C++ mode via non-standard extensions), I think that's what's confusing many people. It's not a problem in mixed-language projects though, just put all the C code into .c files and all C++ code into .cpp and you're set, compiling C code with a C++ compiler isn't such a great idea anyway, since it limits you to a ca. 1995 version of C.
petre 6y ago
Why not write it in betterC? https://dlang.org/spec/betterc.html https://dlang.org/spec/betterc.html
- flohofwoe 6y ago
  Because despite the name this "betterC" is not a C dialect, but a D dialect which is an entirely different language than C99? Could just as well ask why not write it in Nim, Zig, Rust, Swift, Kotlin etc... This means a different audience, different target platforms, different trade-offs.