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: Paul Eggert <eggert at cs dot ucla dot edu>
- To: Roland McGrath <roland at hack dot frob dot com>
- Cc: Joseph Myers <joseph at codesourcery dot com>, libc-alpha at sourceware dot org
- Date: Tue, 18 Nov 2014 14:29:05 -0800
- 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> <546BB1B1 dot 50000 at cs dot ucla dot edu> <20141118211808 dot 2053D2C3B22 at topped-with-meat dot com>
On 11/18/2014 01:18 PM, Roland McGrath wrote:
We should only ever disable warnings with the
tightest possible scope around where we know for sure we need to.
In that case neither my patch nor Joseph's should be accepted. If I
understand Joseph's patch correctly,the maybe-uninitialized warning
needs to be disabled only when dereferencing'cp'. For example, in the
expression 'cp[cnt]', the warning should be disabled only for the load
from 'cp[cnt]'; it should not be disabled for the load from 'cp' itself,
or for the load from 'cnt'. So Joseph's proposed patch doesn't have a
tight scope here. It should be possible to tighten itto cover only the
places where troublesome dereferences actually occur, e.g., by defining
a macro 'NO_MAYBE_UNINITIALIZED_DEREFERENCE (p)' that suppresses the
warning while dereferencing the pointer P, by using
'NO_MAYBE_UNINITIALIZED_DEREFERENCE (cp + cnt)' in place of 'cp[cnt]', etc.
Also, as I understand it the warning should be disabled only on x86-64,
and only if optimization is enabled, as we don't know of problems with
other platforms or when optimization is turned off.
There may be other ways to tighten the scope, too.
However, I'm still not convinced that it's worth the trouble to insist
on tight scopes like this. Many of these bogus warnings are due to
compiler bugs; I'm afraid we've seen this too often in gnulib, when
supporting projects that use -Werror. If we start worrying about tight
scopes for workarounds for GCC cry-wolf bugs, we will too easily go down
the rabbit hole of maintaining a fragile and evolving list of GCC
compiler bugs rather than maintaining glibc.