* David Brown: > On 11/10/2023 10:10, Florian Weimer wrote: >> * David Brown: >> >>> So IMHO (and as I am not a code contributor to GCC, my opinion really >>> is humble) it is better to be stricter than permissive, even in old >>> standards. It is particularly important for "-std=c89", while >>> "-std=gnu89" is naturally more permissive. (I have seen more than >>> enough terrible code in embedded programs - I don't want to make it >>> easier for them to write even worse code!) >> We can probably make (say) -std=gnu89 -fno-permissive work, in a way >> that is a bit less picky than -std=gnu89 -pedantic-errors today. >> > > The gcc manual has "-permissive" under "C++ Dialect Options". Are you > planning to have it for C as well?
Yes, I've got local patches on top of Jason's permerror enhancement: [PATCH v2 RFA] diagnostic: add permerror variants with opt <https://inbox.sourceware.org/gcc-patches/20231003210916.1027930-1-ja...@redhat.com/> > That sounds like a good idea (perhaps with some examples in the > documentation?). Ideally (and I realise I like stricter checking than > many people) some long-obsolescent features like non-prototype > function declarations could be marked as errors unless "-permissive" > were used, even in C89 standards. For some of such declarations, this falls out of the implicit-int removal. C23 changes meaning of of extern foo(); to match the C++ interpretation of extern foo(void);. I don't think we should warn about that. If we warn, it would be at the call site. > (As a side note, I wonder if "-fwrapv" and "-fno-strict-aliasing" > should be listed under "C Dialect Options", as they give specific > semantics to normally undefined behaviour.) They are code generation options, too. >> And of course there's still -Werror, that's not going to go away. So if >> you are using -Werror=implicit-function-declaration today (as you >> probably should 8-), nothing changes for you in GCC 14. > > I have long lists of explicit warnings and flags in my makefiles, so I > am not concerned for my own projects. But I always worry about the > less vigilant users - the ones who don't know the details of the > language or the features of the compiler, and don't bother finding > out. I don't want default settings to be less strict for them, as it > means higher risks of bugs escaping out to released code. We have a tension regarding support for legacy software, and ongoing development. I think we should draw the line at C99. That's the first language standard that removes most of these obsolescent features, after all. Thanks, Florian
