From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32307 invoked by alias); 25 Aug 2005 17:22:50 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 32224 invoked by alias); 25 Aug 2005 17:22:38 -0000 Date: Thu, 25 Aug 2005 17:23:00 -0000 Message-ID: <20050825172238.32223.qmail@sourceware.org> From: "mark at codesourcery dot com" To: gcc-bugs@gcc.gnu.org In-Reply-To: <20050825153435.23561.jakub@gcc.gnu.org> References: <20050825153435.23561.jakub@gcc.gnu.org> Reply-To: gcc-bugzilla@gcc.gnu.org Subject: [Bug rtl-optimization/23561] nonoverlapping_memrefs_p returns true even for overlapping memory references X-Bugzilla-Reason: CC X-SW-Source: 2005-08/txt/msg02935.txt.bz2 List-Id: ------- 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