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

[Marcus Müller]

Hi Paul,

Sorry to  respectfully contradict you here: introducing a macro really doesn't 
do readability and immediate clarity of effect any better than a commented 
zero-initialization.

I also disagree with your approach being less of a submission to the false (or 
over-arching) compiler warnings: you literally introduce two different code 
paths just to make a compiler happy. That is IMHO much more of an accommodation 
than just actually initializing the variable. Your macro is much more of a 
pollution than the simple
 = 0; // initializing to silence false warning in gcc 12.2, see bug#9999
would be, since it would be confusing without the comment, and redundant with, 
plus, again, I consider code paths that intentionally differ between debug and 
release builds detrimental to code quality, due to reduced representativeness 
of debugging for real world.

Generally, when I (and I fully realize that this describes me, not anyone else 
necessarily) read codes trying to understand bugs, I dread macros. They require 
jumping around in code, break scoping rules, and potentially introduce 
conditionality where clarity would be preferred.

The original white_add macro which gcc falsely finds a -1 in, which kicked off 
this thread? That should really not be part of any code base. If your macros 
use locals that aren't passed as macro parameters, they're not ugly, but 
harmful to maintainers... IMHO. My respect for the humans dealing with this 
1995 code of limited beauty.
However, your proposed macro is just ugly, as I need to jump around in code to 
see what it does, I might need to figure out under which circumstances any of 
the lint preprocessor variables are set, to see whether for my current run the 
variable is initialized or not. For the reader's sanity's sake - initialize it. 
That has no real downside but your feeling that you for some reason did not 
stand up to GCC by putting a macro where a =0 would have done.

Sorry to disagree so strongly,
Best,
Marcus


Am 15. März 2023 23:42:49 MEZ schrieb Paul Eggert <eggert@cs.ucla.edu>:
>On 3/15/23 02:41, Marcus Müller wrote:
>
>> If my compiler doesn't optimize it away, well, then I have caused very 
>> little overhead.
>
>It's not really a question of overhead. Unecessary initializations make code 
>harder to understand. Polluting code with unnecessary initializations together 
>with comments like /* Initialize this variable to pacify gcc 13.1 x86-64 when 
>compiled with -Wall -O2; see <https://bugs.gnu.org/99999>. */ is better, but 
>it also gets in the way of code ability (and is so rarely done right that I 
>hesitate even mentioning it). Making code hard to understand (and/or hard to 
>write correctly) drives up maintenance costs and that makes bugs more likely.
>
>This sort of code pollution is the tail wagging the dog. The goal should not 
>be to pacify compilers' false alarms. The goal should be to have code that 
>works correctly, is easy to understand, is efficient, etc.
>
>We should of course encourage compiler-writers to write smarter compilers with 
>fewer false alarms, and we can do that by filing bug reports (which I do) and 
>getting these false alarms fixed (which does happen). This approach is better 
>in the long run than polluting the source code.
>
>If these sorts of false alarms were a real problem, we could disable them with 
>the appropriate -Wno-... option, rather than polluting the code to work around 
>them. However, the false alarms we're talking about, which occur when 
>compiling with -O0 -Wmaybe-initialized warnings, are not worth worrying about. 
>We can just ask people not to use that combination of options (since it's 
>counterproductive) and we can leave the code alone. And that is what we should 
>do here.

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.