From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21023 invoked by alias); 20 Aug 2007 16:44:33 -0000 Received: (qmail 19106 invoked by uid 48); 20 Aug 2007 16:44:23 -0000 Date: Mon, 20 Aug 2007 16:44:00 -0000 Message-ID: <20070820164423.19105.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/msg01407.txt.bz2 ------- Comment #17 from manu at gcc dot gnu dot org 2007-08-20 16:44 ------- (In reply to comment #16) > (In reply to comment #15) > > > Of course, the output is '5' and not '0'. So yes, atoi() seems perfectly able > > to initialize buf. (or perhaps, I am still confused). > > Since use() (like atoi) can't know whether its argument is a local automatic > or a global variable, there is no way for it to reliably initialize its > argument. Casting away constness invokes undefined behavior if the static > type of the object is const. But it seems that the current policy of GCC is to not assume that such functions actually take this into account, since when optimizing constants are not propagated beyond a call to such function. This is either the intended behaviour or a missed-optimisation. It would be nice if it would be a missed-optimisation. Fixing that will probably fix PR33086 and help to fix this one. Otherwise, if this is the intended behaviour, then both PRs are invalid as Andrew said. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10138