safety: null checks
Ola Fosheim Grøstad
ola.fosheim.grostad at gmail.com
Mon Nov 23 11:39:21 UTC 2020
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.
More information about the Digitalmars-d
mailing list