On 02/06/2023 00:50, Alejandro Colomar via Gcc-help wrote:
Hi! I was just wondering if there are any plans to drop support of C89 (and gnu89) at any point in the future. I didn't find any such discussion in the mailing list. That change would probably break very ancient code (implicit int, implicit function declarations, ...), but such code is very likely to have been updated in the last several decades to be at least compatible with C99, so I don't expect that much breakage. Most big projects have already migrated, with only a few still resisting (curl comes to mind). But again, I think they use a subset that would compile under C99 with little or no modification. I guess supporting C89 keeps a lot of extra complexity in GCC's source code itself, and maybe even hinders some optimizations. Cheers, Alex
The majority of the C89/C90 -> C99 changes were additions to the language, so that code which was valid C89/C90 would be equally valid and have the same semantics when viewed as C99. Some things, such as implicit int, were already deprecated (or obsolescent - I forget which) in C89/C90 and removed in C99. But there are other things that changed, such as the type of some constants. And the addition of new identifiers to some of the standard headers could conflict with user code.
It is rare that code which compiles with "-std=c90" would not also compile with "-std=c99" and have identical semantics, but it definitely can happen. And backwards compatibility with existing code is a very strong argument for any decision about C tools.
And in some fields, C89/C90 (or "ANSI C", as it is often called, somewhat inaccurately) is still the standard. People working with such code want to use "-std=c90 -Wpedantic" to be as sure as they can be that the code will be usable with every C compiler, even old or obscure ones.
David
