Le 02/03/2012 11:56, Jacob Carlborg a écrit :
>>
>> False.
>>
>> -----------------------
>> import std.stdio;
>>
>> class Foo
>> {
>> final void bar()
>> {
>> writeln("I'm null!");
>> }
>> }
>>
>> void main()
>> {
>> Foo foo;
>> foo.bar();
>> }
>> -----------------------
>>
>> % dmd test.d -O -release -inline
>> % ./test
>> I'm null!
>> %
>>
>> -----------------------
>>
>> You only get an error if there is a memory access involved (vtable,
>> member data etc.)
>>
>
> I never thought about that.
>

This is a common C++ interview question.

Am 02.03.2012, 05:37 Uhr, schrieb Nathan M. Swan <nathanmswan@gmail.com>:

> I spent a long time trying to find a
> bug that crashed the program before writeln-debugging statements
> could be flushed.

Instead of writeln use stdout.writeln.

Am 02.03.2012, 14:01 Uhr, schrieb deadalnix <deadalnix@gmail.com>:

> Le 02/03/2012 11:56, Jacob Carlborg a écrit :
>>>
>>> You only get an error if there is a memory access involved (vtable,
>>> member data etc.)
>>>
>>
>> I never thought about that.
>>
>
> This is a common C++ interview question.

Don't scare him! I only had interviews in small companies with self-educated programmers. One question was, what Delphi cannot do. I said, writing a kernel and cross-platform development wouldn't work, but the answer the employer was looking for was COBRA. (And I think even at that time there was already a solution for that.)
The difficulty really depends on how sophisticated a company's personnel department is. :-)

Le 02/03/2012 14:30, Marco Leise a écrit :
> Am 02.03.2012, 14:01 Uhr, schrieb deadalnix <deadalnix@gmail.com>:
>
>> Le 02/03/2012 11:56, Jacob Carlborg a écrit :
>>>>
>>>> You only get an error if there is a memory access involved (vtable,
>>>> member data etc.)
>>>>
>>>
>>> I never thought about that.
>>>
>>
>> This is a common C++ interview question.
>
> Don't scare him! I only had interviews in small companies with
> self-educated programmers. One question was, what Delphi cannot do. I
> said, writing a kernel and cross-platform development wouldn't work, but
> the answer the employer was looking for was COBRA. (And I think even at
> that time there was already a solution for that.)
> The difficulty really depends on how sophisticated a company's personnel
> department is. :-)

Yes, many company don't go that far in interview. But this is a red flag to me.

On 2012-03-02 14:00, deadalnix wrote:
> Le 02/03/2012 05:51, Jonathan M Davis a écrit :
>> On Friday, March 02, 2012 05:37:46 Nathan M. Swan wrote:
>>> Am I correct that trying to use an Object null results in
>>> undefined behavior?
>>>
>>> Object o = null;
>>> o.opCmp(new Object); // segmentation fault on my OSX machine
>>>
>>> This seems a bit non-D-ish to me, as other bugs like this throw
>>> Errors (e.g. RangeError).
>>>
>>> It would be nice if it would throw a NullPointerError or
>>> something like that, because I spent a long time trying to find a
>>> bug that crashed the program before writeln-debugging statements
>>> could be flushed.
>>
>> It's defined. The operating system protects you. You get a segfault on
>> *nix and
>> an access violation on Windows. Walter's take on it is that there is
>> no point
>> in checking for what the operating system is already checking for -
>> especially
>> when it adds additional overhead. Plenty of folks disagree, but that's
>> the way
>> it is.
>>
>
> The assertion that it has overhead isn't true.You'll find solutions
> without overhead (using libsigsegv in druntime for example).
>
> BTW, object should be non nullable by default, if you ask me. The
> drawback of null is way bigger than any benefit.

Isn't it quite unsafe to throw an exception in a signal ?

-- 
/Jacob Carlborg

Le 02/03/2012 15:37, Jacob Carlborg a écrit :
> On 2012-03-02 14:00, deadalnix wrote:
>> Le 02/03/2012 05:51, Jonathan M Davis a écrit :
>>> On Friday, March 02, 2012 05:37:46 Nathan M. Swan wrote:
>>>> Am I correct that trying to use an Object null results in
>>>> undefined behavior?
>>>>
>>>> Object o = null;
>>>> o.opCmp(new Object); // segmentation fault on my OSX machine
>>>>
>>>> This seems a bit non-D-ish to me, as other bugs like this throw
>>>> Errors (e.g. RangeError).
>>>>
>>>> It would be nice if it would throw a NullPointerError or
>>>> something like that, because I spent a long time trying to find a
>>>> bug that crashed the program before writeln-debugging statements
>>>> could be flushed.
>>>
>>> It's defined. The operating system protects you. You get a segfault on
>>> *nix and
>>> an access violation on Windows. Walter's take on it is that there is
>>> no point
>>> in checking for what the operating system is already checking for -
>>> especially
>>> when it adds additional overhead. Plenty of folks disagree, but that's
>>> the way
>>> it is.
>>>
>>
>> The assertion that it has overhead isn't true.You'll find solutions
>> without overhead (using libsigsegv in druntime for example).
>>
>> BTW, object should be non nullable by default, if you ask me. The
>> drawback of null is way bigger than any benefit.
>
> Isn't it quite unsafe to throw an exception in a signal ?
>

The signal handler is called on top of the stack, but the information to retrieve the stack trace are system dependant. BTW, using lib like libsigsegv can help a lot to make it safe. It isn't safe ATM, but it is doable.

"Peter Alexander" <peter.alexander.au@gmail.com> wrote in message news:vicaibqyaerogseqsjbe@forum.dlang.org...
> On Friday, 2 March 2012 at 04:53:02 UTC, Jonathan M Davis wrote:
>>
>> It's defined. The operating system protects you. You get a segfault on
>> *nix and
>> an access violation on Windows.
>
> False.
>
> -----------------------
> import std.stdio;
>
> class Foo
> {
>     final void bar()
>     {
>         writeln("I'm null!");
>     }
> }
>
> void main()
> {
>     Foo foo;
>     foo.bar();
> }
> -----------------------
>
> % dmd test.d -O -release -inline
> % ./test
> I'm null!
> %
>
> -----------------------
>
> You only get an error if there is a memory access involved (vtable, member data etc.)
>

Technically speaking, there is no dereference of null occurring there. It *looks* like there is because of the "foo.bar" notation, but remember, calling a member function is not really dereferencing. It's just sugar for:

foo.vtable[index_of_bar](foo);

Since "bar()" is a final member of "Foo" and "foo" is statically known to be type "Foo", the usual vtable indirection is unnecessary, so it reduces to:

bar(foo);

Passing null into a function doesn't involve dereferening the null, and bar() doesn't dereference "this", so there's never any dereferencing of null. Therefore the rule about null dereferences always being caught does still hold true.

It is counter-intuitive, though.

> Technically speaking, there is no dereference of null occurring there. It
> *looks* like there is because of the "foo.bar" notation, but remember,
> calling a member function is not really dereferencing. It's just sugar for:
>
> foo.vtable[index_of_bar](foo);
>
But usually there's an class invariant.

On Friday, 2 March 2012 at 10:01:32 UTC, Daniel Murphy wrote:
> "Peter Alexander" <peter.alexander.au@gmail.com> wrote in message
> news:vicaibqyaerogseqsjbe@forum.dlang.org...
>>>
>>> It's defined. The operating system protects you. You get a segfault on *nix and
>>> an access violation on Windows.
>>
>> False.
>>
>> [snip]
>>
>> You only get an error if there is a memory access involved (vtable, member data etc.)
>>
>
> It _is_ defined, you get an access violation whenever there's a dereference.
> Yes, you can call some types of member functions without any dereferences,
> but this is alse well defined and sometimes quite useful.

Ok, if it is defined, then please tell me what the defined behaviour of my code snippet is.

On Friday, March 02, 2012 16:19:13 deadalnix wrote:
> Le 02/03/2012 15:37, Jacob Carlborg a écrit :
> > On 2012-03-02 14:00, deadalnix wrote:
> >> Le 02/03/2012 05:51, Jonathan M Davis a écrit :
> >>> On Friday, March 02, 2012 05:37:46 Nathan M. Swan wrote:
> >>>> Am I correct that trying to use an Object null results in undefined behavior?
> >>>> 
> >>>> Object o = null;
> >>>> o.opCmp(new Object); // segmentation fault on my OSX machine
> >>>> 
> >>>> This seems a bit non-D-ish to me, as other bugs like this throw
> >>>> Errors (e.g. RangeError).
> >>>> 
> >>>> It would be nice if it would throw a NullPointerError or something like that, because I spent a long time trying to find a bug that crashed the program before writeln-debugging statements could be flushed.
> >>> 
> >>> It's defined. The operating system protects you. You get a segfault on
> >>> *nix and
> >>> an access violation on Windows. Walter's take on it is that there is
> >>> no point
> >>> in checking for what the operating system is already checking for -
> >>> especially
> >>> when it adds additional overhead. Plenty of folks disagree, but that's
> >>> the way
> >>> it is.
> >> 
> >> The assertion that it has overhead isn't true.You'll find solutions without overhead (using libsigsegv in druntime for example).
> >> 
> >> BTW, object should be non nullable by default, if you ask me. The drawback of null is way bigger than any benefit.
> > 
> > Isn't it quite unsafe to throw an exception in a signal ?
> 
> The signal handler is called on top of the stack, but the information to retrieve the stack trace are system dependant. BTW, using lib like libsigsegv can help a lot to make it safe. It isn't safe ATM, but it is doable.

You could definitely set it up to print a stack trace in the signal handler on at least some systems, but throwing an exception would _not_ be a good idea. So, a NullPointerException _would_ require additional overhead, because it would require checking the pointer/reference for null every time that you dereference it.

Of course, it wouldn't work if anyone installed their own signal handler, so using a signal handler has its limits anyway, but it could be done.

- Jonathan M Davis