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

[Paul Eggert <eggert@cs.ucla.edu>]

Eli Zaretskii wrote:

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

GCC does not enable this particular warning by default, and it's not likely ever 
to do so given the high rate of false alarms. People run into warnings like this 
because Emacs 'configure' enables them, and Emacs 'configure' is our 
responsibility.
> I call GCC_LINT "tinkering".

Developers and builders should not need to tinker in the typical case, if the 
default settings are OK. And developers using unusual tools will likely need to 
specify special arguments to 'configure' or 'make' anyway, so that's OK.

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

Valgrind is one. There are also proprietary tools such as Coverity, QA-C, and 
Oracle Studio. Although they don't catch every use-before-set bug, they catch 
enough to be useful and they are practical to use. Admittedly they might not be 
*trivial* to use, but they aren't that hard and they don't (or at least 
shouldn't) require changing the Emacs source code.

Valgrind works with Emacs master as-is, if you configure Valgrind and Emacs 
correctly and avoid having Emacs call library functions that rely on undefined 
behavior (Gtk has some, unfortunately, so I typically use -nw when using 
Valgrind to debug Emacs).  I have used Valgrind to find and fix 
uninitialized-memory bugs in Emacs that would have been very difficult to find 
simply by using GDB or by staring at the code.  As far as I know Valgrind is the 
best free tool for debugging some types of low-level errors that GCC does not 
diagnose, and this includes some significant classes of use-before-set bugs.