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.) T -- Notwithstanding the eloquent discontent that you have just respectfully expressed at length against my verbal capabilities, I am afraid that I must unfortunately bring it to your attention that I am, in fact, NOT verbose.