Issue ID: 16526
Summary: @safe code should do null check for members when
OS: Mac OS X
If I have a struct like this:
I can access memory I'm not supposed to, even in @safe code, that is beyond the
void main() @safe
S * ptr;
ptr.data = 5;
This data could be unmapped or mapped (on my 64-bit system, it's not mapped, so
a segfault still occurs). But it is a possible way to have an exploit in @safe
I propose that if the compiler can detect at compile-time that access to a
member of a struct is beyond the zero page if a pointer happens to point at
null, then it should check for a null pointer (actually, it should just
dereference the first word pointed at by the pointer, and trigger a segfault).
It only needs to do this once if it can determine the pointer or reference will
If the access to the member is determined at compile-time to point within one
page of the front of the struct pointer (either by knowing at compile time the
index being accessed, or knowing that the struct is less than one page in
size), then no instrumentation is needed.
If the access cannot be determined to be within one page at compile-time, then
the check should still be made during runtime.
If one takes a reference to a member that is outside the one-page limit, then
the same check can be performed. There are still ways to access data beyond one
page without incurring a check with this scheme, but we are talking about very
weird and rare code.
This scheme should leave most code intact, and in rare cases, add a few null
checks here and there. Note that by null check, you aren't actually checking
against null, but simply using the built-in ability to segfault. So it's cheap.