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/[email protected] > > 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
