safety: null checks

[Ola Fosheim Grøstad]

On Monday, 23 November 2020 at 02:21:20 UTC, ag0aep6g wrote:
> What I meant is that DMD allows dereferencing null in @safe 
> code. Since @safe code must not corrupt memory, it must then 
> take the necessary steps to make that safe.

Yes, the implementation dereferences null and traps it, but the 
in terms of the language it prevents dereferencing of null and 
terminates (as the dereferencing is supposed to be without other 
side effects than termination).

> I'm pretty sure that DMD doesn't actually take the necessary 
> steps (as you say, it ignores large objects). And I'm not sure 
> if Walter has fully considered the implications, but he has 
> made it clear that null is supposed to be a safe value. And 
> that can be made to work fairly easily, at the cost of run-time 
> checks. Maybe treating null as unsafe could also work, but that 
> would need a lot more design work.

Yes, that does pose problems with objects of variable size. So 
then you either have to put a limit of how large objects nullable 
pointers are allowed to point to or add runtime checks.

This is a good reason to add nonnullable pointers to the 
language. That would reduce the number of places where you need 
dynamic checks.

> I think that's an implementation detail. An implementation must 
> ensure that null is safe (at least in @safe code). We don't 
> really care how it does that, but adding checks before every 
> dereference is the obvious solution.

Indeed. Although specifications sometimes add implementation 
notes to clarify how things are supposed to work (so that an 
embedded compiler doesn't ignore runtime checks altogether).

In the case of D, it would be interesting and useful to have 
implementation notes referring to what the different D compilers 
do.