Disallow null references in safe code?

Andrei Alexandrescu SeeWebsiteForEmail at erdani.org
Sat Feb 1 13:19:27 PST 2014


On 2/1/14, 1:11 PM, Walter Bright wrote:
> On 2/1/2014 12:09 PM, Andrei Alexandrescu wrote:
>> On 2/1/14, 2:14 AM, Jonathan M Davis wrote:
>>> How is it unsafe? It will segfault and kill your program, not corrupt
>>> memory.
>>> It can't even read any memory. It's a bug to dereference a null
>>> pointer or
>>> reference, but it's not unsafe, because it can't access _any_ memory,
>>> let
>>> alone memory that it's not supposed to be accessing, which is
>>> precisely what
>>> @safe is all about.
>>
>> This has been discussed to death a number of times. A field access
>> obj.field
>> will use addressing with a constant offset. If that offset is larger
>> than the
>> lowest address allowed to the application, unsafety may occur.
>>
>> The amount of low-address memory protected is OS-dependent. 4KB can
>> virtually
>> always be counted on. For fields placed beyond than that limit, a
>> runtime test
>> must be inserted. There are few enough 4KB objects out there to make this
>> practically a non-issue. But the checks must be there.
>
> Another way to deal with it is to simply disallow @safe objects that are
> larger than 4K (or whatever the size is on the target system).

This seems like an arbitrary limitation, and one that's hard to work 
around without significant code surgery. I think the true solution is 
runtime checks for fields beyond the 4K barrier. They will be few and 
far between and performance-conscious coders already know well to lay 
out all hot data at the beginning of the object.

Andrei



More information about the Digitalmars-d mailing list