Jeff Law via Gcc <gcc@gcc.gnu.org> writes:
> On 9/26/23 02:28, Florian Weimer via Gcc wrote: >> My understanding of the consensus goes as follows: >> * We want to make some changes in this area for GCC 14. >> * We should do the same thing that Clang does: default to the relevant >> -Werror= options. >> * Unlike regular warnings, these warnings-as-errors should also apply >> to system headers. >> * At least implict-int and implicit-function-declaration should be >> upgraded to errors in this way. >> * It's too early to make the () changes and bool-as-keyword from C2X >> for GCC 14. >> * We should fix the missing scope of the int-conversion warnings >> (PR109827). Likweise for incompatible-pointer-types (PR109826). >> Is this summary accurate? > I wasn't there, so I can't attest to accuracy. It does look like a > reasonable plan for gcc-14 though. > >> I think the open issues are: >> * Do we want to implement something else beside implicit-int and >> implicit-function-declaration? (Candidates are int-conversion and >> incompatible-pointer-types, and the void vs non-void part of >> return-type, maybe others as previously discussed on the list.) >> * How do we divide up the test suite cleanup work? > Not to open a can of worms, but shouldn't these be evaluated along the > same basic criteria? ie, what's Clang doing here, are these > warnings-as-errors and thus apply to system headers, etc. ANd the > biggie, do any of these issues tend to mask correctness errors in the > wild at a level roughly similar to implicit > int/implicit-function-declaration? My experience from doing the big rebuilds in Gentoo and working on patches is that int-conversion often comes up with completely broken code like wrong strerror_r variant (glibc vs musl) or with structs being initialised with the wrong members (not using C99 desig. initialisers and then differences with padding or similar). I don't think I can recall a harmless hit. Incompatible pointer types are a mix - sometimes it's harmless, but a lot of the infringers aren't great (again often indicating wrong prototypes being used or missing feature test macros). It's helped to find a lot of typos as well. The only real snag (which isn't a big deal IMO) is that it'll flag up attribute mismatches for function pointer types, at least with Clang, but that's not a big deal. Clang has done both of these (technically Clang has only done incompatible *function* pointer types rather than all incompatible pointer types, at least for now though). > > Jeff