There are situations where derefering null pointer shouldn't be considered UB (this == nullptr)

[Christiano]

I started this discussion here:
https://groups.google.com/forum/#!topic/comp.lang.c++/AspSSs0SaIo

The book Programming: Principles and Practice with C++ 2nd edition presents the following code, Page 620 (2nd edition, fourth print):

//------------code1----------------
Link* Link::insert(Link* n)    // insert n before this object; return n
{
           if (n==nullptr) return this;
           if (this==nullptr) return n;
           n–>succ = this;              // this object comes after n
           if (prev) prev–>succ = n;
           n–>prev = prev;            // this object’s predecessor becomes n’s predecessor
           prev = n;                        // n becomes this object’s predecessor
           return n;
}

See this line:
           if (this==nullptr) return n;

It is saying that you can call the insert method using as "Link *" a pointer to null.
Example:
Link *p = nullptr; // EMPTY LIST
p = p->insert(new Link{"Athena"}); // INSERTING ATHENA
// p is pointing to Athena now.
// p-->[athena]

The problem is: Several peoples insist to say that it is UB:
https://www.google.com/#q=this+null+c%2B%2B
When in fact the standard is not very clear on that.

These people say that the standard should be clearer in saying that this is UB.
What I am trying to say with this post is the opposite. Of course there are situations (most cases) where dereference a null pointer is a wrong code.
But it would be a terrible mistake to consider that "code1" UB, since it is not.

Being more clear:
There are situations where dereference null pointer is obviously a wrong code.
but
There are situations where dereference null pointer is just a good technique.

[Hyman Rosen]

It is undefined behavior to call a member function using a null pointer.  Compilers are free to replace "this == nullptr" with "false" at compile time.  It is a terrible mistake to consider "code1" undefined behavior, since it is not.  However, calling Link::insert through a null Link pointer is a terrible mistake, as that is undefined behavior.

It's undefined behavior because the standard says that p->f() is considered to be (*p).f(), and it is undefined behavior to indirect a null pointer.  And of course it's undefined for practical reasons too; if the called function is virtual, there is no object from which the final overrider can be determined.

[Christiano]

> It is undefined behavior to call a member function using a null pointer.

Show me One place in the standard that says it directly.
In my research I just see people repeating it without proof.

> However, calling Link::insert through a null Link pointer is a terrible mistake

Where is the mistake in that code? There is no mistake there.

> And of course it's undefined for practical reasons too; if the called function is virtual, there is no object from which the final overrider can be determined.

If insert were virtual, that code would be wrong, but it is not virtual.
That is: There are situations where derefering null pointer shouldn't be considered UB.

[Chris Hallock]

On Wednesday, July 5, 2017 at 9:47:05 AM UTC-7, Christiano wrote:

[question on whether this == nullptr implies UB]

The Standard isn't clear and there is an open defect report related to this. See CWG issue 232.

Even the Committee's intent isn't clear (to me), because the Rationale for rejected CWG issue 315 implies that (*myNullPtr).FunctionThatDoesntUseThisPtr() ought to be allowed, whereas the last comment on 232 suggests that it ought to be UB.

[Richard Smith]

The difference is that in core issue 315, the member function is a static member function.

This makes more sense if you think of non-static member functions as being passed an implied first parameter that is a reference to the class type. (The fact that 'this' is a pointer rather than a reference is a historical accident.) Just like any other reference parameter, it can't be bound to a dereferenced null pointer. But a static member function has no such parameter; the lvalue expression denoting the object is evaluated and then discarded, and null ("empty") lvalues are OK so long as you don't bind a reference to them or try to access an object through them.

[Chris Hallock]

Ah, thanks for clarifying.

[languag...@gmail.com]

So the rejection of the issue 315 means that `*p` for `p == nullptr` never was UB by itself?

среда, 5 июля 2017 г., 23:32:24 UTC+3 пользователь Richard Smith написал:

[Andrew Marlow]

On 30 July 2017 at 07:46, <languag...@gmail.com> wrote:

So the rejection of the issue 315 means that `*p` for `p == nullptr` never was UB by itself?

среда, 5 июля 2017 г., 23:32:24 UTC+3 пользователь Richard Smith написал:

On 5 July 2017 at 11:07, Chris Hallock <christoph...@gmail.com> wrote:

On Wednesday, July 5, 2017 at 9:47:05 AM UTC-7, Christiano wrote:

[question on whether this == nullptr implies UB]

The Standard isn't clear and there is an open defect report related to this. See CWG issue 232.

That link is only for committee members. A more open link is https://wg21.cmeerw.net/cwg/issue232 

--

Regards,

Andrew Marlow
http://www.andrewpetermarlow.co.uk

[Chris Hallock]

That's new. wg21.link used to redirect to the public issue lists on www.open-std.org.

[Richard Smith]

Around the times of committee meetings, wg21.link points to the committee-internal versions of papers.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-discussion+unsubscribe@isocpp.org.
To post to this group, send email to std-dis...@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-discussion/.