Re: aliasing warnings: help

[Michael Chamberlain <michael at chamberlain dot net dot au>]

On Thu, Sep 30, 1999 at 04:36:32PM -0700, Joe Buck wrote:
> Zack writes:
> > For example, consider the following:
> > 
> > enum alg_code { a, b, c };
> > struct algorithm
> > {
> >   enum alg_code op[32];
> > };
> > 
> > unsigned int
> > synth_mult_ok (alg_out)
> >      struct algorithm *alg_out;
> > {
> >   return *alg_out->op;
> > }
> > 
> > unsigned int
> > synth_mult_bad (alg_out)
> >      struct algorithm *alg_out;
> > {
> >   return *(enum alg_code *)alg_out;
> > }

> point to an element of op.  So even if the code is technically wrong
> (and I'm not sure that it is), it's harmless for now.  Remember, the
> goal is to try to warn about code that may break due to strict aliasing
> optimizations.
> 
> What if we just suppress the warning in both cases?  That is, don't
> warn if we cast a struct to the type of the first element.

If I'm not mistaken, the C standard guarantees that a pointer to a struct
and a pointer to the first element of the struct are interchangeable. I
can't remember the exact circumstances under which this applies (it may
only work for structs in structs, as I believe that was the main reason it
was guaranteed), but if it does apply then both code snippets would be
strictly conforming.

Michael.
-- 
 ______________________________________________
|  Michael Chamberlain | The best response to  |
| Chamberlain Computer | a rhetorical question |
|  Services Pty. Ltd.  |  is the wrong answer  |