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

[Marcus Müller]

Hi Paul,

Uff, being a newb to this community, I feel really bad about giving my 2ct to roughly the 
first thing I read on the mailing list, but:

Let's not do what GNU emacs does.

Having different code when linting and not linting makes bugs that only happen in 
non-debug/lint builds impossible to find. That's a terrible price to pay. And for what? If 
I'm doing a release build, the optimizing compiler would never load that initial value if 
it's never getting read. If my compiler doesn't optimize it away, well, then I have caused 
very little overhead.

I'm all for documenting clearly why something was done; whether that happens in a comment 
or a good git commit message depends on the project style.

Best regards,
Marcus

On 14.03.23 22:49, Paul Eggert wrote:
> On 3/14/23 09:50, Pádraig Brady wrote:
> > The attached also addresses -Wmaybe-initialized warnings in coreutils
> > that show up at lower optimization levels.
>
> Let's not make that sort of change, please. It makes the code harder to read and 
> analyze, because I look at the code and wonder, "why is this variable being initialized 
> when it doesn't need to be?" And it doesn't insulate the code against the smarter 
> compilers of the future, which I presume will warn us against unnecessary assignments.
>
> If you're going to make that sort of change, at least do what GNU Emacs does:
>
>   /* 'int x UNINIT;' is equivalent to 'int x;', except it cajoles GCC
>    into not warning incorrectly about use of an uninitialized variable. */
>   #if defined GCC_LINT || defined lint
>   # define UNINIT = {0,}
>   #else
>   # define UNINIT /* empty */
>   #endif
>
> and then say "int x UNINIT;" instead of "int x;". But personally I would leave things 
> alone and ask people to use better compiler options that don't generate so many false 
> positives.