3 ms·
That makes sense when you realize that what C folks care about more than anything else is _ABI compatibility_. Changes to language or toolchain are acceptable a
by pdw 2y ago
That makes sense when you realize that what C folks care about more than anything else is _ABI compatibility_. Changes to language or toolchain are acceptable as long as they don't change the ABI.
E.g. consider the hemming and hawing about a 64-bit time_t. That's a tiny change in comparison, and one that's obviously unavoidable and with a strict deadline. And yet...
- kukkamario 2y ago64-bit time has already been resolved in newer 32-bit Linux versions. Issue isn't that changing ABI couldn't be done. It is that no one wants to update OS and custom software of a 15-year-old embedded system that still works. Archeology to find correct instructions to build a working OS image is challenge itself and then there is a need to adapt them to more modern tools. Been there, done that, and it wasn't fun...
- zzo38computer 2y ago> E.g. consider the hemming and hawing about a 64-bit time_t. I had received a compiler warning about this when trying to compile a program on Raspberry Pi (it was a old version; I did this a few days before they implemented 64-bit time_t on Raspberry Pi). Fortunately I was able to add a macro to allow it to work on computers without 64-bit time_t. Other than that, the program I compiled worked perfectly, although I wrote the program on PC and did not specifically try to make it work with Raspberry Pi. So, a C code is portable, although sometimes a few changes are required to make the program to work. But I think that 64-bit time_t is a good idea.