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 22:47:29 +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> <alpine dot DEB dot 2 dot 10 dot 1411211807540 dot 2475 at digraph dot polyomino dot org dot uk> <546F8FA5 dot 2050702 at cs dot ucla dot edu>
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