From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14669 invoked by alias); 20 Aug 2007 17:12:18 -0000 Received: (qmail 13922 invoked by uid 48); 20 Aug 2007 17:12:03 -0000 Date: Mon, 20 Aug 2007 17:12:00 -0000 Message-ID: <20070820171203.13921.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug middle-end/10138] warn for uninitialized arrays passed as const* arguments In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "manu at gcc dot gnu dot org" Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2007-08/txt/msg01415.txt.bz2 ------- Comment #20 from manu at gcc dot gnu dot org 2007-08-20 17:12 ------- (In reply to comment #19) > > What if you had "const int i=0"? As I said before, use() may do a const-cast > to get rid of the constness of its argument, but the result is only > well-defined > if the object pointed to is actually non-const. That is the case here, so use() > may do exactly this and clobber 'i'. On the other hand, if 'i' was const, then > the result of any const-cast use() may do on its argument are undefined, and > it would seem legitimate to propagate the initial value of 'i' into the call > to foo(). > Wolfgang, I understand perfectly what you explain. Yet, from the point of view of Wuninitialized, only local non-const objects are interesting. And it seems that for those, GCC does not assume that the function is not going to modify the object. Thus, it doesn't make much sense for Wuninitialized to assume it. And, from a technical point of view, it would be difficult to maintain such dichotomy, since Wuninitialized relies on the SSA representation and the work of the optimisation passes. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10138