> On Dec 2, 2015, at 21:28, Jens Alfke <[email protected]> wrote:
> 
> 
>> On Dec 2, 2015, at 5:18 PM, Doug Hill <[email protected] 
>> <mailto:[email protected]>> wrote:
>> 
>> "Certain other operations are described in this International Standard as 
>> undefined (for example, the effect of dereferencing the null pointer). 
>> [Note: this International Standard imposes no requirements on the behavior 
>> of programs that contain undefined behavior. ]”
> 
> Not relevant; I already explained in a previous reply that this does not 
> dereference a null pointer. You can call nonvirtual methods on NULL pointers 
> just fine without any runtime issues … just as long as you don’t access any 
> member variables, of course.
> 
>> The problem seems to be that you can make up C++ code that constructs a NULL 
>> pointer and then crash when you dereference it. My understanding is that the 
>> C++ spec unequivocally defines this as an error and therefor it shouldn’t be 
>> happening at all. 
> 
> It’s not a weird situation at all. Something returns you an object pointer. 
> You call a method on that object. But the pointer you got happens to be NULL. 
> Ergo, you’ve just called a method on a NULL pointer.
>       Widget *w = factory.getCurrentWidget();
>       Paint *p = w->getPaint();
> If the currentWidget is NULL, the second line does this.

That counts as a pointer dereference (the special case of &*foo is just that, a 
special case).

> In some circumstances it’s useful to be able to handle this — heck, we should 
> be able to agree on this, since we use this handy behavior of messaging nil 
> in Obj-C all the time. So Widget::getPaint() could check for this==nil and if 
> so return NULL instead of crashing.
> 
> It’s not a big deal; I’ve adjusted my code not to do this. I was just curious 
> where this tightening of the standard came from.

I don’t think this was a result of a tightening of the standard, IIRC, this was 
*always* undefined behavior.


 _______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list      ([email protected])
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/xcode-users/archive%40mail-archive.com

This email sent to [email protected]

Reply via email to