public inbox for gcc-help@gcc.gnu.org
 help / color / mirror / Atom feed
From: Segher Boessenkool <segher@kernel.crashing.org>
To: Jonny Grant <jg@jguk.org>
Cc: Xi Ruoyao <xry111@mengyan1223.wang>, 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 11:22:52 -0500	[thread overview]
Message-ID: <20210703162252.GI1583@gate.crashing.org> (raw)
In-Reply-To: <80eacded-aa7d-52c1-1fd4-6ec1a987c311@jguk.org>

On Sat, Jul 03, 2021 at 03:14:21PM +0100, Jonny Grant wrote:
> 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.

There *is* no generic way you can sanely and even safely handle null
pointer dereferences at all.  You *have to* separately write code for
every place you want to do something special with null pointers (or any
other special case for that matter).

In case you are talking about a system with an event loop (or similar),
where you can just abort the task you are doing, and get back to waiting
for more work to do: you can just catch *all* fatal errors (which a null
dereference normally is), log it, and go back to the main loop.  But
even then the null dereference could be caused by something that is not
yet fixed.  If you are lucky other tasks can still be done.   OTOH,
perhaps just as often nothing will work anymore.

In any case, there is nothing the compiler can do for you here.  If
programming were a mechanical job, we wouldn't need all those pesky
programmers :-)


Segher

  reply	other threads:[~2021-07-03 16:23 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
2021-07-03 16:22             ` Segher Boessenkool [this message]
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=20210703162252.GI1583@gate.crashing.org \
    --to=segher@kernel.crashing.org \
    --cc=gcc-help@gcc.gnu.org \
    --cc=jg@jguk.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).