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

[Marcus Müller]

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 <eggert@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.