Po Lu via Gcc <gcc@gcc.gnu.org> writes: > 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.
Much of the thread (including the original post) does discuss that and it's not limited to implicit-int.
signature.asc
Description: PGP signature
