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

[Joseph Myers]

On Fri, 21 Nov 2014, Paul Eggert wrote:

> A couple of other thoughts.
> 
> First, the syntax DIAG_IGNORE (-Wmaybe-uninitialized, ...) is too clever and
> brittle.  Too clever, because in C code it looks like it's subtracting
> 'uninitialized' from the negative of 'Wmaybe'.  Too brittle, because suppose
> GCC adds a warning option syntax with commas in it?
> "-Wsuggest-attribute=format,noreturn", say?  Then DIAG_IGNORE
> (-Wsuggest-attribute=format,noreturn, ...) won't work because of C's
> tokenization rules.  For both of these reasions it would be better to use a
> string, e.g., DIAG_IGNORE ("-Wmaybe-uninitialized", ...).

That seems reasonable, but does anyone else have comments on it?

>   off_t size IF_LINT ( = 0);
> 
> when GCC wrongly complains that 'size' may be used unininitialized.  That way,
> people who want to use -Wmaybe-uninitialized can get clean compiles by
> compiling with '-Wmaybe-uninitialized -Dlint', and people who don't care about
> this stuff can omit the options and get slightly more-efficient code.
> Obviously there are some pitfalls in this approach but overall its benefits
> outweigh its cost for us.  In particular, it lets us carefully isolate the
> uninitialized-warning bug, whereas the DIAG_IGNORE approach is more of a
> blunderbuss that disables the warning in a too-large region because of GCC's
> bugs.

I believe it's established glibc practice not to add initializations that 
would change generated code to silence warnings.  In any case, 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]" (this is a case where for these particular findidx calls the 
out-of-bounds access is unreachable, but GCC doesn't see that - very much 
like -Warray-bounds bogus warnings sometimes seen on some architectures 
for one or two files), and initializing within the bounds doesn't stop the 
warning.

-- 
Joseph S. Myers
joseph@codesourcery.com