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: Fri, 18 Jun 2021 09:53:45 -0500	[thread overview]
Message-ID: <20210618145345.GT5077@gate.crashing.org> (raw)
In-Reply-To: <ffa2f90f-e1c9-4dc7-8f42-fddd1229063b@jguk.org>

On Thu, Jun 17, 2021 at 09:44:27PM +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?
> 
> 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.

That doesn't make too much sense really.  Check pointer and then do
what?  Your code can check for null pointers itself, of course.

Anyway, without any sanitize options, from the following code:

int f(int *p) { return *p; }
int g(void) { return f(0); }

you get on powerpc64le:

f:
	lwa 3,0(3)
	blr
g:
	li 9,0
	lfiwax 0,0,9
	trap

or on aarch64:

f:
	ldr     w0, [x0]
	ret
g:
	mov     x0, 0
	ldr     w0, [x0]
	brk #1000

or on x86_64:

f:
	movl    (%rdi), %eax
	ret
g:
	movl    0, %eax
	ud2

GCC knows the code after the load is not reachable, that is why it
generates a trap instruction there.  I will still do the load though, so
that you get good errors and a reasonable debug experience.


Segher

  parent reply	other threads:[~2021-06-18 14:54 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
2021-07-06 10:33               ` Jonny Grant
2021-06-18  8:38         ` Liu Hao
2021-06-18 14:53         ` Segher Boessenkool [this message]
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=20210618145345.GT5077@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).