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