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.
