Re: aliasing warnings: help

[Joe Buck <jbuck at synopsys dot COM>]

Zack writes:

> I've been working on aliasing warnings for awhile now.  The sticking
> point is the number of spurious warnings you get with any approach,
> which makes them nearly useless.
> 
> 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;
> }

In this case, we have difficulty distinguishing between a pointer to
a struct, and a pointer to the first element of the struct.  But does
this matter?  Could we generate bad code from the usage in the second
function?  It seems to me that the answer is no: we have a pointer
to alg_code, and we have a struct containing such a field.  If I
understand right, Mark's code has to assume that the pointer might
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.