Re: aliasing warnings [patch]

[Joe Buck <jbuck at synopsys dot COM>]

Mark Mitchell writes (on Zack's patch):
> I expect your patch will be useful to some people.  Good work!

Seconded.  It was one of the few bright spots in the 500+ gcc messages
I just plowed through (I was away for two weeks).

> I looked at a few of the warnings that were generated with GCC this
> way.  I was not surprised to see that all of them (in my spot check of
> five or six) were false positives of the same form: a pointer is cast
> to a different type, but then uncast before it is used.

Of course, we get a false positive if the problematic pointer is never
dereferenced, since the error is not the generation of such a pointer,
but dereferencing.

What if, instead of immediately issuing a warning, instead you simply tag
the tree for the pointer somehow?  The idea is to mark pointers that are
unsafe to dereference.  If the pointer is later dereferenced, you could do
a pedwarn (as the program unquestionably breaks the strict ANSI/ISO rules,
and that's what -pedantic is for).  If it goes out of scope without being
dereferenced, no problem.  The only problematic case is if it is on the
heap, passed to a function, etc.  You could optionally generate a warning
for such cases.

Someone mentioned that DEC's compiler issues warnings of this type
and that's how the Perl team became aware of the issue.  The above
approach seems like a clean way to get such warnings, for the case
where all the code is in the same function.

The RMS variant (sure to be contoversial) would be to put a pointer with
this tag into alias set 0 (it can alias everything).

This general idea could be extended to generate other types of warnings.
For example, the "one off the end" pointer is blessed by the C standard
and elevated into a core principle in the C++ STL.  Such pointers are
legal to generate and do pointer arithmetic for but it is not valid to
dereference them.  Again, they could be tagged and the tag checked.