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