Re: Add macros for diagnostic control, use them in locale/weightwc.h

[Joseph Myers <joseph at codesourcery dot com>]

On Fri, 21 Nov 2014, Paul Eggert wrote:

> Joseph Myers wrote:
> > it's established glibc practice not to add initializations that
> > would change generated code to silence warnings.
> 
> Sure, and that's what the IF_LINT macro calls do in coreutils, Emacs, etc.:
> they don't alter the code used in production.  In practice this leads to code
> that is definitely easier to maintain and arguably more resistant against
> faults than the DIAG_IGNORE approach being proposed.

The idea for glibc is to use -Werror in production (as per 
<https://sourceware.org/ml/libc-alpha/2012-08/msg00404.html> - "It's 
especially important to catch subtle regressions when building releases.") 
- which means warnings need to be avoided in production as well.

> > that doesn't appear to help for the case this patch relates to; the
> > uninitialized object '*((void *)&str+4)' is outside the bounds of "UCHAR
> > str[1]"
> 
> If GCC is griping about (say) some component of the array xyz not being
> initialized, then in the worst case one can pacify it by initializing the
> array in its declaration, e.g., 'int xyz[100] IF_LINT (= {0});'.  Of course if
> GCC is griping only about xyz[2], one can tighten this by initializing just
> xyz[2], which is preferable.  In my experience, it's rare to need to do
> anything so drastic as to initialize an entire array, as GCC warning bugs
> generally have to do with local scalars.

As I understand this warning, it's warning about str[1] for an array 
wint_t str[1] for which only str[0] is valid and only str[0] exists to be 
initialized (but the - unreachable - code is, after propagating some 
constants, accessing str[1]).  So it's not possible to initialize the 
element warned about without also increasing the size of the array (and 
experimentally, initializing the existing element makes no change to the 
warning).

-- 
Joseph S. Myers
joseph@codesourcery.com