public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jeff Law <law@redhat.com>
To: Florian Weimer <fweimer@redhat.com>,
	Andrew Haley <aph@redhat.com>,
	       Jeff Prothero <jprother@altera.com>,
	gcc@gcc.gnu.org
Subject: Re: Obscure crashes due to gcc 4.9 -O2 => -fisolate-erroneous-paths-dereference
Date: Fri, 20 Feb 2015 17:01:00 -0000	[thread overview]
Message-ID: <54E76858.40600@redhat.com> (raw)
In-Reply-To: <54E71E4A.3050503@redhat.com>

On 02/20/15 04:45, Florian Weimer wrote:
> On 02/20/2015 10:30 AM, Andrew Haley wrote:
>> I doubt that such a thing is ever going to be safe.  The idea that a
>> null pointer points to nothing is so hard-baked into the design of C
>> that you can't get away from it.  Also, almost every C programmer and
>> especially library writer "knows" that a null pointer points to
>> nothing.
>
> NULL pointer dereferences (or NULL pointer with small offsets) were
> common programming idioms in the DOS days because the interrupt vector
> table was located at this address.  Quite a few systems once had a
> readable page zero, and (manual, I assume) optimizations for list
> traversal (p != NULL && p->next != NULL → p->next != NULL) were commonly
> used on these systems.
True, but thankfully this isn't blessed anymore.


>
> I think the treatment of pointers not as addresses, but something that
> has type information and provenience associated with it, came much
> later, when most of the design was already settled.
We still have targets where page0 is special.  The H8 for example comes 
to mind.  Folks regularly place data into page0 and mark it as special 
so the compiler emits more efficient sequences to access that data.

Regardless, the right thing to do is to disable elimination of NULL 
pointer checks on targets where page 0 is mapped and thus a reference to 
*0 may not fault.  In my mind this is an attribute of both the processor 
(see H8 above) and/or the target OS.

On those targets the C-runtime had better also ensure that its headers 
aren't decorated with non-null attributes, particularly for the mem* and 
str* functions.

jeff

  reply	other threads:[~2015-02-20 17:01 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-02-18 19:24 Jeff Prothero
2015-02-18 19:29 ` Jakub Jelinek
2015-02-19 20:56   ` Sandra Loosemore
2015-02-19 21:16     ` Daniel Gutson
2015-02-19 22:10       ` Jakub Jelinek
2015-02-19 22:26         ` Sandra Loosemore
2015-02-19 21:23     ` Joel Sherrill
2015-02-19 21:56       ` Chris Johns
2015-02-20 17:30         ` Jeff Law
2015-02-26 16:23           ` David Malcolm
2015-02-27 20:55             ` [RFC/patch for stage1] Embed compiler dumps into generated .o files (was Re: Obscure crashes due to gcc 4.9 -O2 => -fisolate-erroneous-paths-dereference) David Malcolm
2015-02-20 11:06     ` Obscure crashes due to gcc 4.9 -O2 => -fisolate-erroneous-paths-dereference Florian Weimer
2015-02-20 11:43       ` Jonathan Wakely
2015-02-20 12:05         ` Florian Weimer
2015-02-20 17:01         ` Jeff Law
2015-02-20 17:09           ` Florian Weimer
2015-02-20 17:32             ` Jeff Law
2015-02-20 18:01           ` Paul_Koning
2015-02-20 12:11       ` Jakub Jelinek
2015-02-20 17:03         ` Jeff Law
2015-03-03 19:57           ` Martin Sebor
2015-03-03 23:38             ` Jeff Law
2015-03-04 12:36               ` Richard Biener
2015-02-20 12:13       ` Andrew Haley
2015-02-20 17:03       ` Jeff Law
2015-02-18 19:30 ` Andrew Pinski
2015-02-20  9:30 ` Andrew Haley
2015-02-20 11:45   ` Florian Weimer
2015-02-20 17:01     ` Jeff Law [this message]
2015-02-20 18:07       ` Paul_Koning
2015-02-20  1:04 Jeff Prothero
2015-02-27 22:13 Manuel López-Ibáñez
2015-03-03  8:41 ` Chris Johns

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=54E76858.40600@redhat.com \
    --to=law@redhat.com \
    --cc=aph@redhat.com \
    --cc=fweimer@redhat.com \
    --cc=gcc@gcc.gnu.org \
    --cc=jprother@altera.com \
    /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).