5 ms·

For new code you can use any language but we do have a lot of C code out there so it would be nice to have some ways to modernize it in, say 10 years, when thos

by t43562 2y ago

For new code you can use any language but we do have a lot of C code out there so it would be nice to have some ways to modernize it in, say 10 years, when those modernizations have made it out to every conceivable platform that runs the software. e.g. GNU make could do very much with some better abstractions (not sure about this one specifically) and yet one cannot use such things until the last VMS user of gmake has got that feature in their C compiler. IMO that probably means the most effective way to modernise C programs might be to transpile the modernisations to e.g. C89. That could be done on any device and the result, one hopes, would work on all the systems out there which might not have the modern compiler on them.

wolletd 2y ago
I wonder how hard it would be to just convert old C code to C++? I mean, most of C just compiles as C++ and does the right thing. There may be some caveats with UB (but less if you don't switch compiler vendor) and minor syntactic differences, but I guess most of them could be statically checked. Or is there any other (performance/size) reason to not do this?
- zabzonk 2y ago
  > most of C just compiles as C++ um, not unless explicitly written to so.
- jay-barronville 2y ago
  > I mean, most of C just compiles as C++ and does the right thing. In my experience, unless you’re strictly talking about header files (which I’m assuming you’re not), C code compiling via C++ compilers is usually hit or miss and highly dependent on the author of the C code having put in some effort into making sure the code actually compiles properly via a C++ compiler. In the overwhelming majority of cases, what lots of folks do is just slap that `extern "C"` in between `#ifdef __cplusplus` and call it a day—that may work for most forward declarations in header files, but that’s absolutely not enough for most C source files. By the way, a great example of C code that does this exceptionally well is Daan Leijen’s awesome mimalloc [0]—you can compile it via a C or C++ compiler and it simply just works. It’s been a while since I read the code, but when I did, it was immediately obvious to me that the code was written with that type of compatibility in mind. [0]: https://github.com/microsoft/mimalloc https://github.com/microsoft/mimalloc
- dundarious 2y ago
  There are pretty fundamental differences in key areas, like zero initialization of a struct or array (`{0}` vs `{}`). Use the C way in C++ and you only 0 the first element or member. Use the C++ way in C and you don't 0 anything. IMO there's no point even attempting a blind recompile of C as C++. A transpiler tool would be needed.
  - plorkyeran 2y ago
    `int array[100] = {0};` results in an array with 100 zeroes in both C and C++. In C if there are too few values the remaining ones are initialized following the same rules as for static variables, and in C++ they're initialized using value initialization. For all types supported by C these have the same result.
- Gibbon1 2y ago
  We could fire WG14 and add Walter Brights fix for passing arrays, buffer and slice types. Add phat pointers and types as fist class objects. If you did that and implemented marking passing size info over function calls then you could probably mechanically convert crappy foo(void *buf, int sz) code to foo(slice_t buf) which would be a lot safer to maintain.
- bsder 2y ago
  The ABI for C++ is a disaster. That alone would doom such a conversion.
- eqvinox 2y ago
  > I mean, most of C just compiles as C++ You're asking about old C code - that code won't compile as C++. And newer C code would likely also be cleaner and not benefit much from being compiled as C++. (And, C++ is a net negative over C anyway due to much poorer reviewability.)
bsder 2y ago
At this point, I think I'd rather that C simply freeze in amber to open the field to its replacement. C is sufficient. There doesn't seem to be anything left that you can do without making it "Not C". Its ABI is the de facto standard. I would rather all the energy go to making a language without the legacy requirements. Programming languages develop very slowly because they are bound by social uptake. Putting C specifically as legacy would help accelerate those timelines.
- t43562 2y ago
  This is typical of software development projects - the "new" replacement wants to kill off the old one so cannot have any improvements happening to the old one. If the new ones are so great though ..... I suspect that quite a lot of maintainers of code don't want to rewrite it particularly and quite a lot of people upstream of that don't want to re-integrate everything to use something new. So little improvements that can be taken a bit at a time are fantastic.
- eqvinox 2y ago
  It's already frozen and the replacement is already there. It's Rust. (Yes there are other competitors, but unless a large shift happens, Rust has won¹´⁴.) The intent of maintaining C is to help maintain the shittons of existing C code. Even if people were to immediately start rewriting everything, it'd take a decade or two until most things have a replacement. And you still need to maintain and update things until then. There's enough work to think about making that task better - especially for safety concerns, like we're talking about here. (And, yeah, sunk cost and whatnot… especially if you're making a commercial product, a rewrite is a hard sell and a lot of C code will live far longer than we all wish. It'll be the COBOL of 2077, I suspect.) ¹ "high-level" C code has a lot of other options and probably shouldn't have been written in C to begin with. For low-level C code, Rust is the most suitable² and popular option, everything else is significantly behind (in popularity/usage at least). That might of course change, but for the time being, it is Rust and Rust is it³. ² this doesn't mean Rust is specifically targeted at or limited to low-level things, it just does them quite well and is a good slot-in for previous C uses. ³ of course C++ was supposed to be "it" the entire time, but at least as far as I'm personally concerned, C++ is a worse disaster than C and needs to be replaced even more urgently. ⁴ I'm aware Zig exists. Call me when it reaches some notable fraction (let's say ⅓) of Rust's ratings on the TIOBE index.

by t43562 2y ago

wolletd 2y ago

I wonder how hard it would be to just convert old C code to C++? I mean, most of C just compiles as C++ and does the right thing. There may be some caveats with UB (but less if you don't switch compiler vendor) and minor syntactic differences, but I guess most of them could be statically checked. Or is there any other (performance/size) reason to not do this?

zabzonk 2y ago
> most of C just compiles as C++ um, not unless explicitly written to so.
jay-barronville 2y ago
> I mean, most of C just compiles as C++ and does the right thing. In my experience, unless you’re strictly talking about header files (which I’m assuming you’re not), C code compiling via C++ compilers is usually hit or miss and highly dependent on the author of the C code having put in some effort into making sure the code actually compiles properly via a C++ compiler. In the overwhelming majority of cases, what lots of folks do is just slap that `extern "C"` in between `#ifdef __cplusplus` and call it a day—that may work for most forward declarations in header files, but that’s absolutely not enough for most C source files. By the way, a great example of C code that does this exceptionally well is Daan Leijen’s awesome mimalloc [0]—you can compile it via a C or C++ compiler and it simply just works. It’s been a while since I read the code, but when I did, it was immediately obvious to me that the code was written with that type of compatibility in mind. [0]: https://github.com/microsoft/mimalloc https://github.com/microsoft/mimalloc
dundarious 2y ago
There are pretty fundamental differences in key areas, like zero initialization of a struct or array (`{0}` vs `{}`). Use the C way in C++ and you only 0 the first element or member. Use the C++ way in C and you don't 0 anything. IMO there's no point even attempting a blind recompile of C as C++. A transpiler tool would be needed.
- plorkyeran 2y ago
  `int array[100] = {0};` results in an array with 100 zeroes in both C and C++. In C if there are too few values the remaining ones are initialized following the same rules as for static variables, and in C++ they're initialized using value initialization. For all types supported by C these have the same result.
Gibbon1 2y ago
We could fire WG14 and add Walter Brights fix for passing arrays, buffer and slice types. Add phat pointers and types as fist class objects. If you did that and implemented marking passing size info over function calls then you could probably mechanically convert crappy foo(void *buf, int sz) code to foo(slice_t buf) which would be a lot safer to maintain.
bsder 2y ago
The ABI for C++ is a disaster. That alone would doom such a conversion.
eqvinox 2y ago
> I mean, most of C just compiles as C++ You're asking about old C code - that code won't compile as C++. And newer C code would likely also be cleaner and not benefit much from being compiled as C++. (And, C++ is a net negative over C anyway due to much poorer reviewability.)

bsder 2y ago

At this point, I think I'd rather that C simply freeze in amber to open the field to its replacement. C is sufficient. There doesn't seem to be anything left that you can do without making it "Not C". Its ABI is the de facto standard. I would rather all the energy go to making a language without the legacy requirements. Programming languages develop very slowly because they are bound by social uptake. Putting C specifically as legacy would help accelerate those timelines.

t43562 2y ago
This is typical of software development projects - the "new" replacement wants to kill off the old one so cannot have any improvements happening to the old one. If the new ones are so great though ..... I suspect that quite a lot of maintainers of code don't want to rewrite it particularly and quite a lot of people upstream of that don't want to re-integrate everything to use something new. So little improvements that can be taken a bit at a time are fantastic.
eqvinox 2y ago
It's already frozen and the replacement is already there. It's Rust. (Yes there are other competitors, but unless a large shift happens, Rust has won¹´⁴.) The intent of maintaining C is to help maintain the shittons of existing C code. Even if people were to immediately start rewriting everything, it'd take a decade or two until most things have a replacement. And you still need to maintain and update things until then. There's enough work to think about making that task better - especially for safety concerns, like we're talking about here. (And, yeah, sunk cost and whatnot… especially if you're making a commercial product, a rewrite is a hard sell and a lot of C code will live far longer than we all wish. It'll be the COBOL of 2077, I suspect.) ¹ "high-level" C code has a lot of other options and probably shouldn't have been written in C to begin with. For low-level C code, Rust is the most suitable² and popular option, everything else is significantly behind (in popularity/usage at least). That might of course change, but for the time being, it is Rust and Rust is it³. ² this doesn't mean Rust is specifically targeted at or limited to low-level things, it just does them quite well and is a good slot-in for previous C uses. ³ of course C++ was supposed to be "it" the entire time, but at least as far as I'm personally concerned, C++ is a worse disaster than C and needs to be replaced even more urgently. ⁴ I'm aware Zig exists. Call me when it reaches some notable fraction (let's say ⅓) of Rust's ratings on the TIOBE index.