@safe and null dereferencing

[H. S. Teoh via Digitalmars-d]

On Thu, Jul 27, 2017 at 11:03:02AM -0400, Steven Schveighoffer via Digitalmars-d wrote:
[...]
> However, there do exist places where dereferencing null may NOT cause
> a segmentation fault. For example, see this post by Moritz Maxeiner:
> https://forum.dlang.org/post/udkdqogtrvanhbotdoik@forum.dlang.org
> 
> In such cases, the compiled program can have no knowledge that the
> zero page is mapped somehow. There is no way to prevent it, or
> guarantee it during compilation.
[...]

There is one flaw with Moritz's example: if the zero page is mapped
somehow, that means 0 is potentially a valid address of a variable, and
therefore checking for null is basically not only useless but wrong: a
null check of the address of this variable will fail, yet the pointer is
actually pointing at a valid address that just happens to be 0.  IOW, if
the zero page is mapped, we're *already* screwed anyway, might as well
just give up now.

One workaround for this is to redefine a null pointer as size_t.max
(i.e., all bits set) instead of 0.  It's far less likely for a valid
address to be size_t.max than for 0 to be a valid address in a system
where the zero page is mappable (due to alignment issues, the only
possibility is if you have a ubyte* pointing to data stored at the
address size_t.max, whereas address 0 can be a valid address for any
data type).  However, this will break basically *all* code out there in
C/C++/D land, so I don't see it ever happening in this lifetime.


T

-- 
Those who've learned LaTeX swear by it. Those who are learning LaTeX swear at it. -- Pete Bleackley