Re: [Emacs-diffs] master 6cd5678: Clarify compiler-pacifier in frame.c

[Eli Zaretskii <eliz@gnu.org>]

> Cc: emacs-devel@gnu.org
> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Mon, 26 Aug 2019 01:15:51 -0700
> 
> Eli Zaretskii wrote:
> 
> > The warnings will re-appear if one
> > compiles outside of Git with suitable GCC options, so the solution is
> > incomplete at best.
> 
> We can't (and shouldn't try to) defend against people compiling Emacs with 
> arbitrary-chosen GCC warning options, as there would be far too many false 
> alarms.

It's not about us, it's about GCC's tendency to turn more and more
warnings on by default.

An explicit initialization with a comment explaining it is a small
price to pay for clean compilation in arbitrary environments.

> > An explicit initialization is a tad better, as it doesn't require any
> > tinkering with obscure settings.
> 
> Neither should UNINIT require tinkering, if users employ default configuration 
> settings.

I call GCC_LINT "tinkering".

> Explicit initialization uses plain C rather than the awkward UNINIT macro, and 
> that is a plus for explicit initialization. However, that's a style issue, and 
> for me it's outweighed by the technical advantage of aiding automated debugging 
> tools that I use occasionally.

If this is just your personal stylistic preference, then I'd question
whether we as a project should accept it.  E.g., my stylistic
preference is different; where does that leave us?

> For these tools it is helpful to say that a variable is not
> initialized, because that helps catch use-before-set errors. An
> explicit initialization would cause these use-before-set bugs to go
> uncaught by these debugging tools.

What debugging tools can make a significant difference here, and how
easy/practical is it to use them?  I very much doubt they will catch
every use-before-set bug anyway.