jwakely....@gmail.com (Jonathan Wakely) writes: > This isn't "be like Clang", this is "diagnose things that have been > invalid C since 1999".
Only if your definition of valid C is ``strictly conforming to the ISO Standard''. I doubt there are many programs which fit such a definition. And anyway, GCC accepts many other constructs which can not be used in a strictly conforming Standard C programs. For example, the use of dollar signs in identifiers. Should we not also reject those, identifier names with external linkage longer than thirty two characters, hex floats, arithmetic on void pointers, zero-length arrays, statement expressions, and so on? > Accepting invalid code by default is a disservice to users. Those who > need to compile invalid C code can use an extra option to allow it, > the default should be to tell users their code is doing something bad. The code is conforming, it simply relies on extensions to the Standard. Implicit int does not break any strictly conforming program, so a C implementation implemented it continues to be conforming, along with those programs relying on implicit int. See this wording in the Standard: A conforming implementation may have extensions (including additional library functions), provided they do not alter the behavior of any strictly conforming program. You are not trying to reject non-conforming C code. You are, for better or worse, trying to impose your personal preferences on users of GCC. Let's debate the real problem at hand instead of using the Standard as a boogeyman: namely, whether or not disabling implicit-int in GCC 14 is a good idea.
