Hello All,

We have a debate going on here about the following snippet of code (see
below) and the "legality" of it.

The chief issue at hand is of course, the use of p->IsNull( ) when p = 0.
The programmer who wrote this code thinks it is okay because the "this"
pointer is "just passed as an argument". It certainly compiles clean and
runs OK on Microsoft Visual C++ 2008.

Any opinions on this code will be well received. Subjectively I dislike this
code immensely, but are there rules in the standard that indicate that this
code is illegal? For example, undefined behaviour on different
architectures? I have instructed the programmer to change it to a static
method and pass the argument in, instead.

PS: Some of you will question why we have an IsNull( ) test in the first
place, as opposed to testing p == 0 directly. Whilst it isn't really
relevant to the question, the reason is that the set of classes in question
is designed to allow a developer to formulate an expression tree using code,
which introduces ambiguity when you want to operate *on* the tree as opposed
to constructing a tree. IsNull( ) exists to alleviate ambiguity in the
intent of the code, when operating *on* the tree.

Thanks

Kevin

---------------------------------------

#include <iostream>

using namespace std;

class Fred
{
public:
bool IsNull( ) { return ( ( void* )this ) == 0; }
};

int main( )
{
Fred* pFred = 0;

if( pFred->IsNull( ) )
cout << "It is null.\n";

return 0;
}





--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

On Aug 6, 7:28 am, "Kevin Frey" <kevin_g_f...@hotmail.com> wrote:
> Hello All,
>
> We have a debate going on here about the following snippet of code (see
> below) and the "legality" of it.
>
> The chief issue at hand is of course, the use of p->IsNull( ) when p = 0.
> The programmer who wrote this code thinks it is okay because the "this"
> pointer is "just passed as an argument". It certainly compiles clean and
> runs OK on Microsoft Visual C++ 2008.
>
> Any opinions on this code will be well received. Subjectively I dislike this
> code immensely, but are there rules in the standard that indicate that this
> code is illegal? For example, undefined behaviour on different
> architectures? I have instructed the programmer to change it to a static
> method and pass the argument in, instead.
>
> PS: Some of you will question why we have an IsNull( ) test in the first
> place, as opposed to testing p == 0 directly. Whilst it isn't really
> relevant to the question, the reason is that the set of classes in question
> is designed to allow a developer to formulate an expression tree using code,
> which introduces ambiguity when you want to operate *on* the tree as opposed
> to constructing a tree. IsNull( ) exists to alleviate ambiguity in the
> intent of the code, when operating *on* the tree.
>
> Thanks
>
> Kevin
>
> ---------------------------------------
>
> #include <iostream>
>
> using namespace std;
>
> class Fred
> {
> public:
> bool IsNull( ) { return ( ( void* )this ) == 0; }
>
> };
>
> int main( )
> {
> Fred* pFred = 0;
>
> if( pFred->IsNull( ) )
> cout << "It is null.\n";
>
> return 0;
>
> }
>

Dereferencing a NULL pointer is officially undefined behavior. So it
can do anything, including "working correctly". However, for some
reason, I can't find the chapter and verse in the Standard. Can
anyone help me find it?


--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

On 2008-08-06 16:28, Kevin Frey wrote:
> Hello All,
>
> We have a debate going on here about the following snippet of code (see
> below) and the "legality" of it.
>
> The chief issue at hand is of course, the use of p->IsNull( ) when p = 0.
> The programmer who wrote this code thinks it is okay because the "this"
> pointer is "just passed as an argument". It certainly compiles clean and
> runs OK on Microsoft Visual C++ 2008.

You are dereferencing a null-pointer, which is not OK (undefined
behaviour). The fact that the code seems to work is just luck.

--
Erik Wikström


[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

On Aug 6, 11:28 pm, "Kevin Frey" <kevin_g_f...@hotmail.com> wrote:
> Hello All,
>

[...]

> Any opinions on this code will be well received. Subjectively I dislike this
> code immensely, but are there rules in the standard that indicate that this
> code is illegal? For example, undefined behaviour on different
> architectures?


Yes, in 1.9/p4, we have

Certain other operations are described in this International
Standard
as undefined (for example, the effect of dereferencing the null
pointer).

so your above code will trigger the undefined behavior.
The log output is meaningless.

Jiang


--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

On 2008-08-06 04:28:24 -0400, "Kevin Frey" <kevin_g_frey@hotmail.com> said:

>
> The chief issue at hand is of course, the use of p->IsNull( ) when p = 0.

That call dereferences a null pointer, so its behavior is undefined.

> The programmer who wrote this code thinks it is okay because the "this"
> pointer is "just passed as an argument". It certainly compiles clean and
> runs OK on Microsoft Visual C++ 2008.

Shrug. The behavior is undefined, so the compiler is free to do anything.

--
Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of "The
Standard C++ Library Extensions: a Tutorial and Reference
(www.petebecker.com/tr1book)



[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

On Aug 6, 12:58 pm, Jiang <goo.mai...@yahoo.com> wrote:
> Yes, in 1.9/p4, we have
>
> Certain other operations are described in this International
> Standard
> as undefined (for example, the effect of dereferencing the null
> pointer).
>

Thanks, Jiang! As far as I can tell, that parenthetical is the *ONLY*
location where null pointer dereferencing is declared undefined.


--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Kevin Frey wrote:
> Hello All,
>
> We have a debate going on here about the following snippet of code (see
> below) and the "legality" of it.
>
> The chief issue at hand is of course, the use of p->IsNull( ) when p = 0.
> The programmer who wrote this code thinks it is okay because the "this"
> pointer is "just passed as an argument". It certainly compiles clean and
> runs OK on Microsoft Visual C++ 2008.

This triggers undefined behavior; that "this" is passed as first
argument to a member function is an implementation detail that is rather
irrelevant to decide whether a member function "works"; And, FYI, such
code did definitely not work in VS7.1. (-; The optimizer assumed there
(quite correctly) that "this" can never be NULL, and might optimize your
function to nothing. Been there, done that. Conclusion: Don't do it.

So long,
Thomas


--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

In article <IpednXNOV5vxQQXVnZ2dnUVZ_qninZ2d@posted.internode >, "Kevin
Frey" <kevin_g_frey@hotmail.com> wrote:

> The chief issue at hand is of course, the use of p->IsNull( ) when p = 0.
> [...]
> bool IsNull( ) { return ( ( void* )this ) == 0; }
> [...]

It's undefined, and here's an example on a compiler of where a null
pointer in does NOT result in a null "this" pointer:

#include <iostream>

struct A { int i; };

struct B { void* get_this() { return this; } };

struct C : A, B { };

void print_ptr( void* p )
{
std::cout << p << " null? " << (p == 0) << '\n';
}

int main()
{
C* c = 0;
print_ptr( c->get_this() ); // prints "0x00000004 null? false"

B* b = 0;
print_ptr( b->get_this() ); // prints "0x00000000 null? true"
}

Note that there are NO virtual functions, yet there's still a pointer
adjustment from C* to B* in this compiler, and it rightly adds it
unconditionally since the object pointer before -> must not be null.

--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

On 6 Aug, 21:58, Jiang <goo.mai...@yahoo.com> wrote:
> Yes, in 1.9/p4, we have
>
> Certain other operations are described in this International
> Standard
> as undefined (for example, the effect of dereferencing the null
> pointer).
>
> so your above code will trigger the undefined behavior.
> The log output is meaningless.
>
> Jiang

At least one passage gives dereferencing a null pointer well-defined
behavior: 5.2.8 [expr.typeid] paragraph 2 says

If the lvalue expression is obtained by applying the unary
* operator to a pointer and the pointer is a null pointer value
(4.10 [conv.ptr]), the typeid expression throws the bad_typeid
exception (18.6.3 [bad.typeid]).

See also core language issue # 232
http://www.open-std.org/jtc1/sc22/wg...ctive.html#232

Roman Perepelitsa.

--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

On Aug 8, 12:58 am, "Roman.Perepeli...@gmail.com"
<Roman.Perepeli...@gmail.com> wrote:
> On 6 Aug, 21:58, Jiang <goo.mai...@yahoo.com> wrote:
>
> > Yes, in 1.9/p4, we have
>
> > Certain other operations are described in this International
> > Standard
> > as undefined (for example, the effect of dereferencing the null
> > pointer).
>
> > so your above code will trigger the undefined behavior.
> > The log output is meaningless.
>
> > Jiang
>
> At least one passage gives dereferencing a null pointer well-defined
> behavior: 5.2.8 [expr.typeid] paragraph 2 says
>
> If the lvalue expression is obtained by applying the unary
> * operator to a pointer and the pointer is a null pointer value
> (4.10 [conv.ptr]), the typeid expression throws the bad_typeid
> exception (18.6.3 [bad.typeid]).
>
> See also core language issue # 232http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#232
>

This issue has been discussed several times in this group.
For the original post, "dereference null pointer will
invoke undefined behavior" is the shortest/best answer
in my mind [refer to the *current* standard].

Actually according to the current standard, the original code
has another undefined behavior. In 9.3.1, we have

If a nonstatic member function of a class X is called for
an object that is not of type X, or of a type derived from X,
the behavior is undefined.

Since there is no such an object of type Fred , calling
Fred's non-static member IsNull will invoke undefined
behavior(Yes, we still have an core issue 315 for it).

I see your point here, add such a supplement is better
in my mind.

Regards,

Jiang


--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]