* Sam James: > Florian Weimer <fwei...@redhat.com> writes: > >> * Richard Biener: >> >>>> Am 09.05.2023 um 14:16 schrieb Florian Weimer via Gcc <gcc@gcc.gnu.org>: >>>> >>>> TL;DR: This message is about turning implicit-int, >>>> implicit-function-declaration, and possibly int-conversion into errors >>>> for GCC 14. >>> >>> I suppose the goal is to not need to rely on altering CFLAGS but >>> change the default behavior with still being able to undo this using >>> -Wno-error= or -Wno-? >> >> That's what Clang does (and the defaults chang along with -std= >> settings). To me, -Werror by default for some warnings seems rather >> hackish. But that's just my personal preference, I do not have a strong >> objection to doing it that way. > > Not that we have to follow Clang, but deviating by adding -fpermissive > (which is a GCC-only flag) for C may not be desirable, and following > Clang would let people use the same method for silencing known-bad > codebases for now.
I think Clang already accepts -fpermissive, so it's not *too* bad? (Presumably it just ignores it.) >> One downside with -Wno- is that some developers jump on this rather >> quickly instead of fixing the real problem. So far, I've seen this in >> both Chromium and the kernel, in fringe areas admittedly, but still. >> The advantage is that there is a familiar workaround to get things >> compiling quickly again, of course. > > I've not seen very much of this so far, FWIW. Only for the more annoying > C23 warnings which have well-documented problems (and unrelated to this, > so I won't go on about it anymore). I think this could be a side effect of our different testing strategies. The kernel -Wno-implicit-function-declaration change looks like it was specifically added to build with Clang 15/16. > But -fpermissive does have a nice property in that it's immediately > obvious you're doing something *terrible* if you use it. Right. > In addition to this, this made me realise something similar to what > Florian was saying wrt whitespace. Passing -Wno-error=... doesn't > always work with some poorly-written build scripts because they split > on '=' (this happens with some CMake when poorly written). Hmm, maybe I've seen this as well but attributed it to whitespace. The -std=gnu89 approach would run into problems with this, too. Thanks, Florian
