4 ms·

> I would love to see this principle updated to set a time limit, along the lines of: existing code that has been maintained to not use features marked deprecat

by sgbeal 3y ago

> I would love to see this principle updated to set a time limit, along the lines of: existing code that has been maintained to not use features marked deprecated, obsolescent, or removed in the past ten years is important; unmaintained code and existing implementations are not. If you cannot update your code to stop relying on deprecated functionality, your code is not actually economically important — people spend time and money maintaining things that are economically important. i have been posting FOSS code since 1998, much of it in C, and not one line of it is something i would dare classify as "economically important." It was written for fun and much of the fun of writing in a language is lost when updates in the language break old code. (The reason i won't touch PHP anymore is because updates broke my long-working code too many times.) C Charter folks: by all means, break long-standing features when folks build with -std=cNEW_VERSION, but keep in mind that -std=c89 or -std=c99 are holy contracts with decades of code behind them, all of which should still compile in 30 years when built in -std=c89/c99 modes, regardless of whether they're "economically important."

saagarjha 3y ago
I don't think that is ever going to change. What might happen is that new compilers drop -std=c89 entirely if they can't support it, but that also seems unlikely.
justincormack 3y ago
Well thats for you to take up with the compiler writers, who have so far done this but it does put a lot of work on them supporting many versions as they diverge.
uecker 3y ago
I think I have the opposite opinion. Newer C standards have a very high degree of backwards compatibility. I think we should try to transition code to the current ISO standard and in almost all cases this will just work without problems. In the few cases, where it does not, it is usually for a very good reason. Now, nobody is stopping compilers from supporting old language modes, but it adds a lot of complexity, not for making the code compile, but for all the diagnostics which are different. If you look at the FE code of GCC, for example, a lot of code is dedicated this. If we could remove all this stuff at some point (which would still allow old code to compile, but one code remove diagnostics for things which were disallowed in earlier standards but are now allowed), then this reduce maintenance burden substantially. And if one really needs those old diagnostics, one could simply go back to an old version of the compiler.
- sgbeal 3y ago
  > I think we should try to transition code to the current ISO standard and in almost all cases this will just work without problems. In the few cases, where it does not, it is usually for a very good reason. Microsoft's C compiler did not support C99 until something like 15 years after the standard came out (and reportedly (according to colleagues who use that platform) still doesn't support certain features of it). It happens with surprising frequency that someone reports to the sqlite project that The Latest Version no longer works on their pre-2005 environment and they'd like to see it patched to work there. My point is: users of a given platform might not be able to use The Latest Stuff (or anywhere near it, for that matter) because their OS vendor is reticent, because they have to support an old platform which is not targeted by newer tools, or for whatever other reason. > Now, nobody is stopping compilers from supporting old language modes, but it adds a lot of complexity, ... i don't doubt that, and i do sympathize with the maintainers. i'm not saying they should never ever remove C89 support, but if they do then there needs to be an alternative, like a fork of the last compiler version which supported it, maintained at least to the extent that the rare genuine compiler bugs can be resolved.
  - uecker 3y ago
    Microsoft declared C dead and wanted that everybody transitions to C++. Luckily this changed a bit and MSVC now supports newer standards. Also there are now other alternatives on Windows. So I do not think there is a good reason to put everything on standstill anymore. C needs to evolve and old code must be maintained. For me, this this means that code should be transitioned to newer standards. In no other industry would it be acceptable to ignore current industry standards. Now, I do understand that some projects do not want to use newer features for portability reasons. But this does not mean that they couldn't be compatible with a newer ISO C modes as well. Being compliant with C 17 does not necessarily mean one has to use new features.
  - pjmlp 3y ago
    Microsoft considered C done, as clarified by Herb Sutter. https://herbsutter.com/2012/05/03/reader-qa-what-about-vc-and-c99/ https://herbsutter.com/2012/05/03/reader-qa-what-about-vc-an... They only kept updating their C support to the extent required by ISO C++ requirements, and some key customers. Anyone else still dependent on C was suggested to use clang, this is also why clang is part of Visual Studio compiler suite nowadays. Around the time the Microsoft <3 Linux stuff started, they decided to backtrack on this matter, and started updating their C support, however since C11 made a couple of stuff from C99 optional, they decided to skip on those. VLAs have anyway been proven a rich source of exploits, to the extent Google has sponsored the work to clean up the Linux kernel from all uses of them. https://www.phoronix.com/news/Linux-Kills-The-VLA https://www.phoronix.com/news/Linux-Kills-The-VLA

by sgbeal 3y ago

saagarjha 3y ago

I don't think that is ever going to change. What might happen is that new compilers drop -std=c89 entirely if they can't support it, but that also seems unlikely.

justincormack 3y ago

Well thats for you to take up with the compiler writers, who have so far done this but it does put a lot of work on them supporting many versions as they diverge.

uecker 3y ago

I think I have the opposite opinion. Newer C standards have a very high degree of backwards compatibility. I think we should try to transition code to the current ISO standard and in almost all cases this will just work without problems. In the few cases, where it does not, it is usually for a very good reason. Now, nobody is stopping compilers from supporting old language modes, but it adds a lot of complexity, not for making the code compile, but for all the diagnostics which are different. If you look at the FE code of GCC, for example, a lot of code is dedicated this. If we could remove all this stuff at some point (which would still allow old code to compile, but one code remove diagnostics for things which were disallowed in earlier standards but are now allowed), then this reduce maintenance burden substantially. And if one really needs those old diagnostics, one could simply go back to an old version of the compiler.

sgbeal 3y ago
> I think we should try to transition code to the current ISO standard and in almost all cases this will just work without problems. In the few cases, where it does not, it is usually for a very good reason. Microsoft's C compiler did not support C99 until something like 15 years after the standard came out (and reportedly (according to colleagues who use that platform) still doesn't support certain features of it). It happens with surprising frequency that someone reports to the sqlite project that The Latest Version no longer works on their pre-2005 environment and they'd like to see it patched to work there. My point is: users of a given platform might not be able to use The Latest Stuff (or anywhere near it, for that matter) because their OS vendor is reticent, because they have to support an old platform which is not targeted by newer tools, or for whatever other reason. > Now, nobody is stopping compilers from supporting old language modes, but it adds a lot of complexity, ... i don't doubt that, and i do sympathize with the maintainers. i'm not saying they should never ever remove C89 support, but if they do then there needs to be an alternative, like a fork of the last compiler version which supported it, maintained at least to the extent that the rare genuine compiler bugs can be resolved.
- uecker 3y ago
  Microsoft declared C dead and wanted that everybody transitions to C++. Luckily this changed a bit and MSVC now supports newer standards. Also there are now other alternatives on Windows. So I do not think there is a good reason to put everything on standstill anymore. C needs to evolve and old code must be maintained. For me, this this means that code should be transitioned to newer standards. In no other industry would it be acceptable to ignore current industry standards. Now, I do understand that some projects do not want to use newer features for portability reasons. But this does not mean that they couldn't be compatible with a newer ISO C modes as well. Being compliant with C 17 does not necessarily mean one has to use new features.
- pjmlp 3y ago
  Microsoft considered C done, as clarified by Herb Sutter. https://herbsutter.com/2012/05/03/reader-qa-what-about-vc-and-c99/ https://herbsutter.com/2012/05/03/reader-qa-what-about-vc-an... They only kept updating their C support to the extent required by ISO C++ requirements, and some key customers. Anyone else still dependent on C was suggested to use clang, this is also why clang is part of Visual Studio compiler suite nowadays. Around the time the Microsoft <3 Linux stuff started, they decided to backtrack on this matter, and started updating their C support, however since C11 made a couple of stuff from C99 optional, they decided to skip on those. VLAs have anyway been proven a rich source of exploits, to the extent Google has sponsored the work to clean up the Linux kernel from all uses of them. https://www.phoronix.com/news/Linux-Kills-The-VLA https://www.phoronix.com/news/Linux-Kills-The-VLA