From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-x42e.google.com (mail-wr1-x42e.google.com [IPv6:2a00:1450:4864:20::42e]) by sourceware.org (Postfix) with ESMTPS id 5C180385700D for ; Sat, 3 Jul 2021 14:14:25 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 5C180385700D Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=jguk.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=jguk.org Received: by mail-wr1-x42e.google.com with SMTP id f14so15754306wrs.6 for ; Sat, 03 Jul 2021 07:14:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jguk.org; s=google; h=from:subject:to:cc:references:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=9XgaNf7UriSOqOMOwzvKIZam96ZFfNdyoaV/g6u61WY=; b=l61cekZzl3fmuTYYXqhe8wgj0W3Fslwnr6ogbg3HMTOUhwAWajr2svn7IsOGTGE7h0 XDm/8/khOuuWcHhDQB1sRCVFljyZUw/DIykOcUEZ+SPab5OCW2kbP7fNqSdKwnGLyBQV abcflYGfgUz1U06m42aoN3zfy4IzfDAmdNiyk7vactBQEns2Ov5E+LXBWHjvU5kwB1x0 po1oxpqzIreNoK2soJgcXbbjtoj79zsMZnKBsEIy8fCsqZaT+8Wle1m/LhzSx2oaPSMz BUf/LDYWWVOlaRMCnJFNgl6auubC3gA9DwN9kxgSIYDg7V1aoIB7ys44iyPbH/rVHmuJ 7KDw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:cc:references:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=9XgaNf7UriSOqOMOwzvKIZam96ZFfNdyoaV/g6u61WY=; b=sf+3woVzSwD6tCKcEnrjLBvwdBq79S7SP2u42SlGTH5sWTSefNGDD77L9NMPHKsnDc fuf29lg2Zoiu5r9Uh8ic7hVj3jq/plXg1rYgNh4qTFhNMM55MQO5EPVpr/q1hI1/tWg3 tTnnuMfWVT/GPyOwy1FKKwtqlKpHYjseTSTsfFcSE/f13mDHaXbfta6eRBWTqSRW5QQz 3MxsEq3WMxOkbOOR7MlCMOl8uJZPsJgGbFzH7OZTGALpBmYEZBZvQRWZcrDdS0aInEoz r127pVYFokMBr8WKlfEuLwgWphA+KXQh55ePZ9djac9S3tkLbTwJZnzJTWtYJ9dhvTgx uuug== X-Gm-Message-State: AOAM531vmhecvXCv3/trVyGLoJY1IVJZ8KIpZncTUpypCRt5BtEABRKr nTaX2gpnJJB1nXkUEER7CmDpcKfllsCLMA== X-Google-Smtp-Source: ABdhPJz3Qy1o3SUYPNjcsxL3pRJCq02klnejqWljhB+X/1EuFKLlXWQ0p6He0QeaxrLEarjnqScxIg== X-Received: by 2002:adf:f482:: with SMTP id l2mr5310400wro.276.1625321663169; Sat, 03 Jul 2021 07:14:23 -0700 (PDT) Received: from [192.168.0.12] (cpc87345-slou4-2-0-cust172.17-4.cable.virginm.net. [81.101.252.173]) by smtp.gmail.com with ESMTPSA id d12sm6915853wri.77.2021.07.03.07.14.22 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 03 Jul 2021 07:14:22 -0700 (PDT) From: Jonny Grant Subject: Re: gcc warn when pointers not checked non-null before de-referencing. To: Xi Ruoyao , Segher Boessenkool Cc: gcc-help References: <0a9ccbb7-135a-b342-e5cb-35b7c6a44a00@jguk.org> <97eb7315fd136ff8a818925b1704760a856ffe64.camel@mengyan1223.wang> <0770e060-6388-fc27-1178-205b867bfae2@jguk.org> <20210616175941.GJ5077@gate.crashing.org> Message-ID: <80eacded-aa7d-52c1-1fd4-6ec1a987c311@jguk.org> Date: Sat, 3 Jul 2021 15:14:21 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3.8 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gcc-help@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-help mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jul 2021 14:14:28 -0000 On 18/06/2021 05:16, Xi Ruoyao wrote: > On Thu, 2021-06-17 at 21:44 +0100, Jonny Grant wrote: >> >> >> On 16/06/2021 18:59, Segher Boessenkool wrote: >>> On Wed, Jun 16, 2021 at 02:01:05PM +0100, Jonny Grant wrote: >>>> I guess a separate static analyser would do it, GCC is more >>>> focused on compilation so I shouldn't ask for it to have so many >>>> features it can't support. >>> >>> -fsanitize=undefined already catches null pointer dereferences, is >>> that >>> enough for your case? >>> >>> >>> Segher >> >> Hello >> Thank you for the suggestion, yes, I had used that before. I did just >> check, it's runtime checks. I had hoped for something at compile time. >> warning for every function that didn't check pointer for NULL before >> de-referencing. > > There is no way to do this. > > int foo(struct dev *dev) > { > int r = sanitize_input(dev); > if (r) > return r; > > bar(&dev->id); > return dev->id->result; > } > > While there is no way to know the behavior of `sanitize_input` (it may > be defined in another TU), there is no way to tell if `foo` has done "a > proper non-null check". Yes, this is a good point, could only check the file that is being compiled. > > And this "warning" does not make any sense. It's perfectly legal for a > function to assume the input is not null and the caller should guarantee > it. Adding a non-null check in every function is just paranoid. This > really looks like a suggestion from some professors who don't program at > all, but unfortunately teach C and tell their own misconcept of > "defensive programming" everywhere. We were taught to be careful what we pass to functions, and careful what we accept in functions, feels appropriate. While I can see that for developer builds, a NULL dereference and core dump would allow a developer to investigate. assert is just as good assert(NULL != ptr); We'd rather have stability and logging of errors than a core dump. Especially on embedded systems that need to guarantee safety. It's easy enough to check for NULL and check the bounds of buffers etc before using. Asserts would trigger in a debug build. I know GCC is a compiler, not a static analyser, so I'll probably run cppcheck Kind regards Jonny