From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 35876 invoked by alias); 30 May 2019 14:48:42 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 35704 invoked by uid 89); 30 May 2019 14:48:25 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS autolearn=ham version=3.3.1 spammy=H*f:sk:22741e1, H*i:sk:22741e1 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 30 May 2019 14:48:14 +0000 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id A5A9A3179B4C; Thu, 30 May 2019 14:48:04 +0000 (UTC) Received: from localhost.localdomain (ovpn-112-56.rdu2.redhat.com [10.10.112.56]) by smtp.corp.redhat.com (Postfix) with ESMTP id BA7661973B; Thu, 30 May 2019 14:48:03 +0000 (UTC) Subject: Re: Question about GCC not warning for some noncompliant SEI CERT C code examples To: Martin Sebor , Fredrik Hederstierna , "gcc@gcc.gnu.org" References: <22741e14-7557-9223-388d-47d9e2b99b08@gmail.com> From: Jeff Law Openpgp: preference=signencrypt Message-ID: <05051cff-f1df-eb7a-c910-5c6a518f0ab5@redhat.com> Date: Thu, 30 May 2019 14:48:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: <22741e14-7557-9223-388d-47d9e2b99b08@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2019-05/txt/msg00260.txt.bz2 On 5/30/19 8:28 AM, Martin Sebor wrote: > On 5/30/19 3:12 AM, Fredrik Hederstierna wrote: >> Hi >> >> When reading the SEI CERT C Coding Standard rules, looking at >> "DCL30-C. Declare objects with appropriate storage durations" >> it seem like GCC does not warn in compile-time for some noncompliant >> examples. >> >> I know eg AddressSanitizer and several runtime running tools finds >> these bugs, >> but it would be convenient of GCC could do some basic static analysis >> already in compile-time to avoid bad code generation. >> Some static analysers finds these bugs, but not all, and GCC does not >> warn. >> >> Example from DCL30-C, not warned by GCC: >> >> >> /* NONCOMPLIANT EXAMPLE-1 */ >> #include >> const char *p; >> void dont_do_this(void) { >>    const char c_str[] = "This will change"; >>    p = c_str; /* Dangerous */ >> } >> void innocuous(void) { >>    printf("%s\n", p); >> } >> int main(void) { >>    dont_do_this(); >>    innocuous(); >>    return 0; >> } >> >> >> /* NONCOMPLIANT EXAMPLE-2 */ >> void squirrel_away(char **ptr_param) { >>    char local[10]; >>    /* Initialize array */ >>    *ptr_param = local; >> } >> void rodent(void) { >>    char *ptr; >>    squirrel_away(&ptr); >>    /* ptr is live but invalid here */ >> } > > Agreed.  This (or a subset of the problem) is being tracked in > PR 69433. > >> >> Question, where in GCC is the most appropriate place to implements >> such a checker? >> I know there are some warnings for return-local-addr, and >> null-pointer-dereference in some different parts, but this seems >> different? >> Can it be found be points-to analysis, or where is it best to put this >> warning if being implemented? > > To me it seems close enough to -Wreturn-local-addr to be implemented > in the same place, in gimple-ssa-isolate-paths.c.  It's worth noting > that besides warning, the pass also clears the returning address and > isolates the path that returns the null in the CFG. > > As it happens, I recently submitted a modest enhancement to > -Wreturn-local-addr to detect returning the addresses of VLAs and > pointers obtained from alloca (PR 71924 and PR 90549).  I'm working > on extending the implementation to returning freed pointers (under > a separate warning option). > > Besides the problems you mention, there is also a related request > to diagnose dereferencing pointers to compound literals whose > lifetime has ended (PR 89990), or more generally, those to any > such local object. > > In the enhancement I submitted I chose not to use the alias oracle > mainly because I didn't want to change the existing design.  I'm > not familiar enough with to tell with confidence if it can be used > to obtain the same results.  I.e., identify each instance of > a local variable that a pointer may point to, rather than just > answering the broad question: does this pointer point to any > local variables?  If it can, using it as Jeff suggests in his > comments, would make sense.  I don't think moving it out of > gimple-ssa-isolate-paths.c is necessary (or even a good idea). Note that you may also be able to use the alias oracle to detect escaping locals. That's likely to have a higher false positive rate, but may still be useful for detecting this kind of stuff. jeff