On Thursday, 10 January 2013 at 01:10:06 UTC, H. S. Teoh wrote:
On Thu, Jan 10, 2013 at 01:50:28AM +0100, Adam D. Ruppe wrote:
On Thursday, 10 January 2013 at 00:18:26 UTC, Walter Bright
wrote:
>And that is not dereferencing null, it is dereferencing
>0x1000000.
Yes, but it is worth noting that dmd will happily compile that
code,
even if marked @safe - just because the pointer on the language
level is null doesn't mean it is memory safe at the assembly
level.
the generated code with @safe is still just what we'd expect
too:
3: 31 c0 xor eax,eax
5: c7 80 00 00 10 00 0a mov DWORD PTR
[eax+0x100000],0xa
Yeah that's exactly what I was thinking too. To DMD, it's a
null pointer
dereference. But actually, it's dereferencing something else,
because
x.fieldName is, in general, *not* null when x is null.
Hmm. This looks like another hole in SafeD? Unless null pointer
checks
are inserted. (The checks have to be made on x, not
x.fieldName, of
course.)
That is exactly why my NPE proposal do trigger on other address
that 0. Still, it require to add check for big objects (or high
indices in arrays).
