Hey everyone, Thanks for coming back to this.
As I said, I'm primarily not a fan of having different code paths depending on build type; that makes debugging harder than necessary. Just a remark, in theory, you can have the cake and eat it, but afterwards your plate will be riddled with the crumbs the doing that causes¹: #pragma GCC diagnostic push #pragma GCC diagnostic ignored "-Wmaybe-uninitialized" The code in question without any conditional initialization #pragma GCC diagnostic pop That should only disable the specific, hand-verified to be false-positive warning, and only for that piece of code, and only for GCC. I'm not advocating for that, though - it feels a bit too verbose. Best, Marcus ¹ my apologies for stretching a metaphor this much. Am 19. Mai 2023 00:20:20 MESZ schrieb Paul Eggert <egg...@cs.ucla.edu>: >On 5/18/23 14:50, Bruno Haible wrote: >> But when "gcc -Wall" reports 10 warnings to me, and I don't notice >> that one of them is an actual bug because I mentally discard all of >> them > >If you're using -O0, then in my experience it's a mistake to also use >--enable-gcc-warnings, as the combination generates too many false positives. >We shouldn't waste time worrying about them, any more than we waste time >worrying about the false positives generated by 'clang -O2' and >--enable-gcc-warnings. > >Especially we should avoid pacifing GCC by adding things like 'IF_LINT (= 0)', >without a really good reason (such as a compiler bug report that we've filed). >The IF_LINT can cause 'gcc -O2' (the typical case) to generate false >negatives, and also it can cause GCC to generate different code for non-debug >builds. Both of these are problematic, and we should not add 'IF_LINT (= 0)' >merely to pacify 'gcc -O0'. > >While I'm on the topic, we should also not worry about other lower-priority >platforms, such as 'gcc -m32' on x86-64. Each such invocation can generate a >boatload of false positives, and in my experience fixing them is more trouble >than it's worth. Of course if you try it on a new platform and find real bugs, >that's another thing - but my experience with running 'gcc -m32' (after a >clean 'gcc -m64' build) is pretty negative. > > >PS. As it happens, I gave a lecture today on static checking of low-level >code, with one topic being GCC's warning diagnostics and their limitations, so >this stuff is fairly fresh in my mind. -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
