f/sta.c:340: warning: dereferencing type-punned pointer will break strict-aliasing rules

[Gabriel Dos Reis]

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