C `restrict` keyword in D

Moritz Maxeiner via Digitalmars-d digitalmars-d at puremagic.com
Mon Sep 4 04:55:14 PDT 2017


On Monday, 4 September 2017 at 10:24:48 UTC, ag0aep6g wrote:
> On 09/04/2017 11:47 AM, Moritz Maxeiner wrote:
>> Still, though, this is surprising to me, because this means 
>> taking the address of a parameter passed by reference (which 
>> is in your case is typed as an existing int) can be null. Is 
>> this documented somewhere (couldn't find it in the spec and it 
>> seems like a bug to me)?
>
> I'm only aware of this part of the spec, which doesn't say much 
> about ref parameters:
>
> https://dlang.org/spec/function.html#parameters
>
> g++ accepts the equivalent C++ code and shows the same 
> behavior. But, as far as I can tell, it's undefined behavior 
> there, because dereferencing null has undefined behavior.
>
> In D, dereferencing a null pointer is expected to crash the 
> program. It's allowed in @safe code with that expectation. So 
> it seems to have defined behavior that way.

Yes, which is why I wrongly assumed that turning a null pointer 
into a reference would crash the program (as such references 
can't be tested for being null, you'd have to turn them back into 
a pointer to test).

>
> But if a dereferencing null must crash the program, shouldn't 
> my code crash at the call site? Or is there an exception for 
> ref parameters? Any way, the spec seems to be missing some 
> paragraphs that clear all this up.

Yes, that is what I meant by saying it looks like a bug to me. It 
really ought to crash at the call site imho; this would require 
injecting null checks at the call site when the argument is a 
pointer dereference.


More information about the Digitalmars-d mailing list