safety: null checks
Patrick.Schluter at bbox.fr
Mon Nov 23 12:28:39 UTC 2020
On Monday, 23 November 2020 at 01:29:12 UTC, Ola Fosheim Grostad
> On Monday, 23 November 2020 at 01:04:38 UTC, Paul Backus wrote:
>> Please show me the definition of null that requires it to be
> null points to nothing, that is not a valid value for the
> referenced type.
No. null is not a trap representation as a C standard would call
it. It is a valid value for a pointer. Dereferencing it is an
entirely other thing.
> Trivially invalid.
>> Please show me the relevant definitions of these terms and
>> explain how they contradict.
> What do mean? A crash is by definition undefined behaviour.
Nope. In the case of D. The error generated by dereferencing a
null pointer is a defined behaviour. As defined as is calling
abort() in a C program.
Catching the error and continuing processing that would be
> The spec does not provide adequate definitions and
> requirements, which is what makes it unsound.
>> The implementation allows undefined behavior in @safe code.
>> That means the implementation is incorrect, period. Neither of
>> the possible interpretations of the spec allow this.
> The spec isn't well defined or consistent just because people
> claim things in the forum.
The issue with null pointer dereferencing has nothing to do with
its definition but with its implementation as the defined
behaviour of aborting the program is not guaranteed in all
circumstances (null pointer + offset big enough to hit a real
More information about the Digitalmars-d