This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Add macros for diagnostic control, use them in locale/weightwc.h
- From: Joseph Myers <joseph at codesourcery dot com>
- To: Paul Eggert <eggert at cs dot ucla dot edu>
- Cc: <libc-alpha at sourceware dot org>
- Date: Fri, 21 Nov 2014 18:12:28 +0000
- Subject: Re: Add macros for diagnostic control, use them in locale/weightwc.h
- Authentication-results: sourceware.org; auth=none
- References: <alpine dot DEB dot 2 dot 10 dot 1411181803130 dot 11642 at digraph dot polyomino dot org dot uk> <alpine dot DEB dot 2 dot 10 dot 1411211705270 dot 2475 at digraph dot polyomino dot org dot uk> <546F79BB dot 80604 at cs dot ucla dot edu>
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