This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Obscure crashes due to gcc 4.9 -O2 => -fisolate-erroneous-paths-dereference

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

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]