This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: f/sta.c:340: warning: dereferencing type-punned pointer will break strict-aliasing rules
- From: Gabriel Dos Reis <gdr at integrable-solutions dot net>
- To: Michael Matz <matz at suse dot de>
- Cc: Mark Mitchell <mark at codesourcery dot com>, Toon Moene <toon at moene dot indiv dot nluug dot nl>, "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- Date: 26 Nov 2002 13:32:24 +0100
- Subject: Re: f/sta.c:340: warning: dereferencing type-punned pointer will break strict-aliasing rules
- Organization: Integrable Solutions
- References: <Pine.LNX.4.33.0211261243170.16743-100000@wotan.suse.de>
Michael Matz <matz@suse.de> writes:
| Hi,
|
| On 25 Nov 2002, Gabriel Dos Reis wrote:
|
| > Right, the warning is really silly in that case. Maybe the
| > type-punning detection machinery should be mabe aware of that rule..
| > But as you I'm not a big fan of that warning in the first place so it
|
| I just wanted to say that for our package maintainers this warning _is_
| usefull. They found already some real problems. But indeed it has too
| many obvious false positives like poor-mans derived-to-base conversions,
| which happen quite a lot in some packages (wine for instance due to the
| err, funny win32 object-oriented-C API).
Yeah, I can understand -- I did something to that effect in some
versions of GCC's own diagnostic.[hc] and in some implementation of
the C/C++ pretty-printer (note yet committed to trunk).
| > will probably end up with low priority in my bucket.
|
| I have no idea about frontends, is there a function which already does a
| prefix test on structs?
I believe something to that effect is impliccilty done at least in the
C++ front-end. But an issue is that the C++ front-end has no clearly
defined architecture of how it (ab)uses trees to represent types and
such. I hope, we will have chances to improve the issue in that area
for 3.4.
| Hmm, now thinking about this: is the use of prefixes really aliasing safe,
| or is that just an gcc extension?
It is safe at least C++ -- and I do believe it is a C inheritance --
here is what the C++ text says:
9.2/17
A pointer to a POD-struct object, suitably converted using a
reinterpret_cast, points to its initial member (or if that member is
a bit-field, then to the unit in which it resides) and vice
versa. [Note: There might therefore be unnamed padding within a
POD-struct object, but not at its beginning, as necessary to achieve
appropriate alignment. ]
-- Gaby