safety: null checks

Patrick Schluter 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 
wrote:
> 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 
>> invalid.
>
> 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.

Nope.

>
>> 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 
undefined behaviour.

>
> 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 
page).



More information about the Digitalmars-d mailing list