View mode: basic / threaded / horizontal-split · Log in · Help
March 02, 2012
Re: dereferencing null
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.
March 02, 2012
Re: dereferencing null
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.
March 02, 2012
Re: dereferencing null
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. :-)
March 02, 2012
Re: dereferencing null
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.
March 02, 2012
Re: dereferencing null
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
March 02, 2012
Re: dereferencing null
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.
March 02, 2012
Re: dereferencing null
"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.
March 02, 2012
Re: dereferencing null
> 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.
March 02, 2012
Re: dereferencing null
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.
March 03, 2012
Re: dereferencing null
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
1 2 3 4 5 6
Top | Discussion index | About this forum | D home