public inbox for gcc-help@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jonny Grant <jg@jguk.org>
To: Xi Ruoyao <xry111@mengyan1223.wang>,
	Segher Boessenkool <segher@kernel.crashing.org>
Cc: gcc-help <gcc-help@gcc.gnu.org>
Subject: Re: gcc warn when pointers not checked non-null before de-referencing.
Date: Sat, 3 Jul 2021 15:14:21 +0100	[thread overview]
Message-ID: <80eacded-aa7d-52c1-1fd4-6ec1a987c311@jguk.org> (raw)
In-Reply-To: <fa05b76faf6eb894d6752d93c7cb24ec4d8f1736.camel@mengyan1223.wang>



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

  reply	other threads:[~2021-07-03 14:14 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-13 22:30 Jonny Grant
2021-06-14  5:15 ` Xi Ruoyao
2021-06-16 13:01   ` Jonny Grant
2021-06-16 13:36     ` Xi Ruoyao
2021-07-03 15:36       ` Jonny Grant
2021-07-06 15:39         ` Xi Ruoyao
2021-07-19 18:20           ` Jonny Grant
2021-06-16 17:59     ` Segher Boessenkool
2021-06-17 20:44       ` Jonny Grant
2021-06-18  4:16         ` Xi Ruoyao
2021-07-03 14:14           ` Jonny Grant [this message]
2021-07-03 16:22             ` Segher Boessenkool
2021-07-06 10:33               ` Jonny Grant
2021-06-18  8:38         ` Liu Hao
2021-06-18 14:53         ` Segher Boessenkool
2021-06-14 15:19 ` Martin Sebor

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=80eacded-aa7d-52c1-1fd4-6ec1a987c311@jguk.org \
    --to=jg@jguk.org \
    --cc=gcc-help@gcc.gnu.org \
    --cc=segher@kernel.crashing.org \
    --cc=xry111@mengyan1223.wang \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).