[Bug rtl-optimization/23561] nonoverlapping_memrefs_p returns true even for overlapping memory references

[mark at codesourcery dot com]

------- Additional Comments From mark at codesourcery dot com  2005-08-25 17:22 -------
Subject: Re:  nonoverlapping_memrefs_p returns
 true even for overlapping memory references

rth at gcc dot gnu dot org wrote:

> And in the case in question, it's quite obviously an off-by-one bug on the
> part of the programmer.  They did not really intend to initialize a3[0] twice.
> So I think it would be useful if _FORTIFY_SOURCE complained about this usage
> even if it turns out to be within the letter of the law.

We did seem to reach the consensus that it was OK to upcast from a 
member of the structure to the containing structure, or, rather, that 
there was nothing that definitively made that invalid.

This is a bit different, in that the problematic memcpy is not 
mentioning a3 at all; it's just stepping on it.  I'm not sure whether 
this case is valid; my guess is that it is, simply in that the C 
standard says so little about the object model that one rather has to 
assume such things are legal.  Then again, you're not strictly pseaking 
allowed to index off the end of an array, so I'm not sure.

However, if memcpy were an arbitrary function, then by the conclusion in 
the first paragraph, it certainly might modify "a.a3".  So, the compiler 
must be making some special assumption about memcpy.  I'd suggest 
ceasing to make that assumption, in the name of caution.

I agree that in an error-checking capacity it makes sense to warn.  As 
RTH says, this is not something that programmers mean to do.



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23561