From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10340 invoked by alias); 10 Apr 2012 12:53:01 -0000 Received: (qmail 10328 invoked by uid 22791); 10 Apr 2012 12:52:59 -0000 X-SWARE-Spam-Status: No, hits=-4.3 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00,KHOP_THREADED X-Spam-Check-By: sourceware.org Received: from localhost (HELO gcc.gnu.org) (127.0.0.1) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 10 Apr 2012 12:52:40 +0000 From: "fredrik.hederstierna@securitas-direct.com" To: gcc-bugs@gcc.gnu.org Subject: [Bug c/52923] Warn if making external references to local stack memory Date: Tue, 10 Apr 2012 12:53:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: c X-Bugzilla-Keywords: diagnostic X-Bugzilla-Severity: enhancement X-Bugzilla-Who: fredrik.hederstierna@securitas-direct.com X-Bugzilla-Status: NEW X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 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: 2012-04/txt/msg00629.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52923 --- Comment #4 from Fredrik Hederstierna 2012-04-10 12:52:36 UTC --- Maybe it have advantages to have a "pointer-deref" analysis pass rather than a "point-to" analysis pass. Then GCC could warn only if the pointer is being dereferenced for real, this to avoid false positives. But in case of shared library-code etc, I guess we never know what users/callers will do with the pointer... Could there possibly be a connection to the work I think maybe Jeff Law and others maybe are doing will null-deref checking pass? I guess they already do some flow analysis and then checking for null-deref rather than 'dangeling-mem-deref' in this case (eg. stack local mem, or free()d-mem). (I think this is done in PR16351.) I also seen the __attribute__((nonnull)) with -Wnonnull, could it be possible perhaps to have some __attribute__((nonlocal)) or similar when declaring pointer? /Fredrik