7 ms·

Musings on the C Charter

56 points by steveklabnik 3y ago

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
buserror 3y ago
I'll start caring about c standards above gnu99 as soon as they add case range values to switch statements, like case A ... B: -- which I've only been using for what, 35 years now? All that time, I really wondered what the flip they are on about. Adding extensions that really, I really raise eyebrows at while ignoring complete elephants in the room, like the above feature. Last year they were pontificating about something something adding some sort of (complicated) syntax to support destructor functions and were wondering about prior implementations, and I had to point to them the support of destructor function had been there as an extension of gcc for countless years. It's like they aren't actually using the language, just speccing it. Kinda like linux maintainers who are more like some sort of priesthood and gatekeepers than actual users of the system.
- saagarjha 3y ago
  The language authors can be shortsighted, but they're not stupid. The discussion of destructors has proceeded for years and everyone there knows that GCC already has __attribute__((cleanup)).
- uecker 3y ago
  Everybody in WG14 is fully aware of the GNU extensions. Also many of us are active C users (but maybe not enough). With complicated syntax you mean the "defer" proposal?. In any case, different people have different priorities and ideas. The best way to influence decisions is to contribute to the standardization process. For example, everybody can submit proposals. But regarding case range values, there is now one: https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3194.htm https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3194.htm
  - rwmj 3y ago
    That defer proposal was the stupidest thing I read in the a long time. Very glad it was rejected.
    - uecker 3y ago
      Well there is a new one: https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3199.htm https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3199.htm But calling things "stupid" is relatively useless internet noise and the best way to be ignored.
rwmj 3y ago
C is doing fine and doesn't need interference. If people want modern C they are better off using other programming languages, and leave the rest of us with giant C codebases alone without creating pointless make-work.
- saagarjha 3y ago
  What are your thoughts on efforts to rewrite your giant C codebase in Rust? Most of the people who hold this opinion also seem to dislike people coming near their code with a new language. Improvements from C are generally driven from a pragmatic viewpoint that there is lots of legacy code that is not being well served by C but cannot afford to be rewritten just yet.
  - rwmj 3y ago
    We've incrementally replaced C objects with OCaml in one project, still linking everything into one final binary. The two languages (or indeed C and Rust, or C and Golang) interoperate fine. You don't need to rewrite the entire project in one go.
- uecker 3y ago
  I think if C does not evolve, some people with giant C codebases will find themselves in the unfortunate position that they suddenly will be shut out of a market by regulators, because the C code is considered a risk, or that they will be liable for bugs caused by preventable memory safety issue, and keeping the code will not be sustainable.
  - rwmj 3y ago
    That's not really the case. For example Airbus has a giant codebase all written in C. It's never going to be rewritten. Instead they apply many tools to it including formals proofs (of both the code and the toolchain). They work closely with the relevant regulators. I'm actually more confident in that process than I would be of some insane plan to rewrite it all in Rust - which would take forever and Rust doesn't have any of the tooling, formally proven compilers, a language specification, more than one implementation, etc etc. People really don't know what they're talking about when they claim C codebases will be rewritten or will "have to be rewritten" because of "regulations", when the regulators are on top of this stuff already.
jeffrallen 3y ago
Don't know if this is an unpopular opinion or not: Today if you are using C it's because you HAVE to (embedded toolchain, historical code, etc). In that case, you use the C you find, not the C in the next version of the standard. So I find the C standard committee's work... uninteresting. Sorry, guys.
- flohofwoe 3y ago
  That's essentially true and actually one of the strengths of C, that the ISO standard is relatively unimportant for real-world projects. The standard is just the minimal supported common language core of a family of C dialects, with the actually interesting stuff happening outside the standard in language extensions and 3rd-party libraries. In a way we can "thank" Microsoft for that. If the MSVC team hadn't boycotted the C standard for nearly two decades, adhering to the C standard would have been more important. But since MSVC didn't support anything past C89 anyway, the C world moved on without them by switching to different compilers.
  - pjmlp 3y ago
    It is easy to blame Microsoft, while forgeting the huge world of embedded devices with proprietary compilers, many of which are still stuck C89 with extensions, as the tiny CPUs hardly do anything better. If anything, I was saddned that they backtraced on their decision to focus on C++. Then again, nowadays thanks to the ongoing security bills, Azure business unit has a roadamp to only use Rust for new systems programming projects, and C#/Go for when managed languages are not an issue, while Visual C++ team seems mostly focused on keeping game developers happy and little else.
    - flohofwoe 3y ago
      SDCC, which is essentially a hobbyist retro-computing compiler for 8-bit and embedded CPUs had and still has better C standard support than MSVC: https://sdcc.sourceforge.net/ https://sdcc.sourceforge.net/ If a couple open source devs can easily out-perform the MSVC team, Visual Studio really is in trouble ;)
binary132 3y ago
I've never really understood the imperative to "move forward". If you want to do something new, do something new. Why break what works?
deleted 3y ago
[deleted]
throwaway17_17 3y ago
The post asks the following question, which brought out a visceral and immediate answer from me: ‘When two implementations support the same notional feature with slightly differing semantics, should the committee use undefined behavior to resolve the conflict so no users have to change code, or should the committee push for well-defined behavior despite knowing it will break some users?’ I lurched towards the second option for ‘well-defined behavior’. And I would answer that way not just despite knowing breakage, but I would say that is the correct choice even in the event of large breakages for some percentage of active code bases. I have a hard time figuring out who would choose to accept more undefined behavior for new semantic constructs. While I may not be accepting of the authors stance and conclusions to the question of ‘Trust the Programmer’, I do agree with his thoughts about the inherent positives of full throated argument in favor of increasing semantic constructs being ‘well-‘ and ‘implementation-‘ defined. I may even go a step further and reach for an ultimate position that if it merely degrades performance metrics by some percentage, then instances of undefined behavior should be eliminated if at all possible. At a minimum, the goal should be to move to, at the most liberal, implementation-defined behavior for any given semantic construct. This would force compiler writers to specify and particularize what syntactic and semantic constructions they were taking advantage of to generate performance gains and allow developers the ability to decide if they could adhere to the implementation’s semantic guarantees.
- eru 3y ago
  > ‘When two implementations support the same notional feature with slightly differing semantics, should the committee use undefined behavior to resolve the conflict so no users have to change code, or should the committee push for well-defined behavior despite knowing it will break some users?’ That's a false dichotomy. You could also use implementation defined behaviour. Or specify that these n behaviours would be valid. 'Undefined behaviour' is too big of a sledgehammer.
- layer8 3y ago
  One important point is that it’s implementers who vote on the C standard. And they may not want to vote for a version that breaks compatibility for their users (but not for users of other, competing implementations). This is one reason why certain semantics remain undefined or implementation-defined.
AdamH12113 3y ago
> 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 think this view is mistaken. Tools that only need small changes rarely are some of the most valuable, because they produce value at minimal cost. > ...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. I understand that you can't support legacy code forever, but we need to get away from this idea that ten years is a long time for software to run, or that only software undergoing constant churn is worth anything.
- jcranmer 3y ago
  Aaron is speaking from experience in trying to get support for prototype-less functions in C removed, something which imposes a surprisingly high burden in the compiler and has been deprecated for over 30 years... and still received a lot of pushback because of the potential of breaking code that hadn't been touched in that time. > I understand that you can't support legacy code forever, but we need to get away from this idea that ten years is a long time for software to run, or that only software undergoing constant churn is worth anything. The specific issue here is the code which lies at the intersection of the three categories: 1. Code that is N decades old and still in active use. 2. Code that needs to be compiled by the latest and greatest compiler versions. 3. Code that no one is willing to invest the resources in to make any changes to keep compiling. That intersection is quite small, if not empty entirely. Consider the programming language with the longest pedigree, Fortran, nearing its 70th birthday, with a large amount of code very firmly meeting the first criterion... and yet I don't think any modern compiler supports anything pre-Fortran 77.
  - fauigerzigerk 3y ago
    There could be larger codebases that are under active development but contain some ancient source files that no one dares to touch any longer. If the latest compilers were to stop supporting old code then some new code could be cut off from further compiler upgrades as well.

56 points by steveklabnik 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

buserror 3y ago

I'll start caring about c standards above gnu99 as soon as they add case range values to switch statements, like case A ... B: -- which I've only been using for what, 35 years now? All that time, I really wondered what the flip they are on about. Adding extensions that really, I really raise eyebrows at while ignoring complete elephants in the room, like the above feature. Last year they were pontificating about something something adding some sort of (complicated) syntax to support destructor functions and were wondering about prior implementations, and I had to point to them the support of destructor function had been there as an extension of gcc for countless years. It's like they aren't actually using the language, just speccing it. Kinda like linux maintainers who are more like some sort of priesthood and gatekeepers than actual users of the system.

saagarjha 3y ago
The language authors can be shortsighted, but they're not stupid. The discussion of destructors has proceeded for years and everyone there knows that GCC already has __attribute__((cleanup)).
uecker 3y ago
Everybody in WG14 is fully aware of the GNU extensions. Also many of us are active C users (but maybe not enough). With complicated syntax you mean the "defer" proposal?. In any case, different people have different priorities and ideas. The best way to influence decisions is to contribute to the standardization process. For example, everybody can submit proposals. But regarding case range values, there is now one: https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3194.htm https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3194.htm
- rwmj 3y ago
  That defer proposal was the stupidest thing I read in the a long time. Very glad it was rejected.
  - uecker 3y ago
    Well there is a new one: https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3199.htm https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3199.htm But calling things "stupid" is relatively useless internet noise and the best way to be ignored.

rwmj 3y ago

C is doing fine and doesn't need interference. If people want modern C they are better off using other programming languages, and leave the rest of us with giant C codebases alone without creating pointless make-work.

saagarjha 3y ago
What are your thoughts on efforts to rewrite your giant C codebase in Rust? Most of the people who hold this opinion also seem to dislike people coming near their code with a new language. Improvements from C are generally driven from a pragmatic viewpoint that there is lots of legacy code that is not being well served by C but cannot afford to be rewritten just yet.
- rwmj 3y ago
  We've incrementally replaced C objects with OCaml in one project, still linking everything into one final binary. The two languages (or indeed C and Rust, or C and Golang) interoperate fine. You don't need to rewrite the entire project in one go.
uecker 3y ago
I think if C does not evolve, some people with giant C codebases will find themselves in the unfortunate position that they suddenly will be shut out of a market by regulators, because the C code is considered a risk, or that they will be liable for bugs caused by preventable memory safety issue, and keeping the code will not be sustainable.
- rwmj 3y ago
  That's not really the case. For example Airbus has a giant codebase all written in C. It's never going to be rewritten. Instead they apply many tools to it including formals proofs (of both the code and the toolchain). They work closely with the relevant regulators. I'm actually more confident in that process than I would be of some insane plan to rewrite it all in Rust - which would take forever and Rust doesn't have any of the tooling, formally proven compilers, a language specification, more than one implementation, etc etc. People really don't know what they're talking about when they claim C codebases will be rewritten or will "have to be rewritten" because of "regulations", when the regulators are on top of this stuff already.

jeffrallen 3y ago

Don't know if this is an unpopular opinion or not: Today if you are using C it's because you HAVE to (embedded toolchain, historical code, etc). In that case, you use the C you find, not the C in the next version of the standard. So I find the C standard committee's work... uninteresting. Sorry, guys.

flohofwoe 3y ago
That's essentially true and actually one of the strengths of C, that the ISO standard is relatively unimportant for real-world projects. The standard is just the minimal supported common language core of a family of C dialects, with the actually interesting stuff happening outside the standard in language extensions and 3rd-party libraries. In a way we can "thank" Microsoft for that. If the MSVC team hadn't boycotted the C standard for nearly two decades, adhering to the C standard would have been more important. But since MSVC didn't support anything past C89 anyway, the C world moved on without them by switching to different compilers.
- pjmlp 3y ago
  It is easy to blame Microsoft, while forgeting the huge world of embedded devices with proprietary compilers, many of which are still stuck C89 with extensions, as the tiny CPUs hardly do anything better. If anything, I was saddned that they backtraced on their decision to focus on C++. Then again, nowadays thanks to the ongoing security bills, Azure business unit has a roadamp to only use Rust for new systems programming projects, and C#/Go for when managed languages are not an issue, while Visual C++ team seems mostly focused on keeping game developers happy and little else.
  - flohofwoe 3y ago
    SDCC, which is essentially a hobbyist retro-computing compiler for 8-bit and embedded CPUs had and still has better C standard support than MSVC: https://sdcc.sourceforge.net/ https://sdcc.sourceforge.net/ If a couple open source devs can easily out-perform the MSVC team, Visual Studio really is in trouble ;)

binary132 3y ago

I've never really understood the imperative to "move forward". If you want to do something new, do something new. Why break what works?

deleted 3y ago

[deleted]

throwaway17_17 3y ago

The post asks the following question, which brought out a visceral and immediate answer from me: ‘When two implementations support the same notional feature with slightly differing semantics, should the committee use undefined behavior to resolve the conflict so no users have to change code, or should the committee push for well-defined behavior despite knowing it will break some users?’ I lurched towards the second option for ‘well-defined behavior’. And I would answer that way not just despite knowing breakage, but I would say that is the correct choice even in the event of large breakages for some percentage of active code bases. I have a hard time figuring out who would choose to accept more undefined behavior for new semantic constructs. While I may not be accepting of the authors stance and conclusions to the question of ‘Trust the Programmer’, I do agree with his thoughts about the inherent positives of full throated argument in favor of increasing semantic constructs being ‘well-‘ and ‘implementation-‘ defined. I may even go a step further and reach for an ultimate position that if it merely degrades performance metrics by some percentage, then instances of undefined behavior should be eliminated if at all possible. At a minimum, the goal should be to move to, at the most liberal, implementation-defined behavior for any given semantic construct. This would force compiler writers to specify and particularize what syntactic and semantic constructions they were taking advantage of to generate performance gains and allow developers the ability to decide if they could adhere to the implementation’s semantic guarantees.

eru 3y ago
> ‘When two implementations support the same notional feature with slightly differing semantics, should the committee use undefined behavior to resolve the conflict so no users have to change code, or should the committee push for well-defined behavior despite knowing it will break some users?’ That's a false dichotomy. You could also use implementation defined behaviour. Or specify that these n behaviours would be valid. 'Undefined behaviour' is too big of a sledgehammer.
layer8 3y ago
One important point is that it’s implementers who vote on the C standard. And they may not want to vote for a version that breaks compatibility for their users (but not for users of other, competing implementations). This is one reason why certain semantics remain undefined or implementation-defined.

AdamH12113 3y ago

> 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 think this view is mistaken. Tools that only need small changes rarely are some of the most valuable, because they produce value at minimal cost. > ...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. I understand that you can't support legacy code forever, but we need to get away from this idea that ten years is a long time for software to run, or that only software undergoing constant churn is worth anything.

jcranmer 3y ago
Aaron is speaking from experience in trying to get support for prototype-less functions in C removed, something which imposes a surprisingly high burden in the compiler and has been deprecated for over 30 years... and still received a lot of pushback because of the potential of breaking code that hadn't been touched in that time. > I understand that you can't support legacy code forever, but we need to get away from this idea that ten years is a long time for software to run, or that only software undergoing constant churn is worth anything. The specific issue here is the code which lies at the intersection of the three categories: 1. Code that is N decades old and still in active use. 2. Code that needs to be compiled by the latest and greatest compiler versions. 3. Code that no one is willing to invest the resources in to make any changes to keep compiling. That intersection is quite small, if not empty entirely. Consider the programming language with the longest pedigree, Fortran, nearing its 70th birthday, with a large amount of code very firmly meeting the first criterion... and yet I don't think any modern compiler supports anything pre-Fortran 77.
- fauigerzigerk 3y ago
  There could be larger codebases that are under active development but contain some ancient source files that no one dares to touch any longer. If the latest compilers were to stop supporting old code then some new code could be cut off from further compiler upgrades as well.