coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: nstrftime.c fails to build due to memset overflow


From: Paul Eggert
Subject: Re: nstrftime.c fails to build due to memset overflow
Date: Thu, 18 May 2023 15:20:20 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.10.0

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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]