Able to call member function with a pointer assigned NULL

[nsharma78]

Hi,

I have a code as follows:

class A
{
public:
void print(){cout << "Magic" << endl;}
};

int main()
{
A* ptrA = NULL;
ptrA->print();
}
The out put is given as Magic.

I wanted to know why is it happening.
In case i add one data member to the class say int i;
then this code will not work.

Can any body explain why?

Thanks

[Noah Roberts]

nsharm...@gmail .com wrote:

Hi,

I have a code as follows:

class A
{
public:
void print(){cout << "Magic" << endl;}
};

int main()
{
A* ptrA = NULL;
ptrA->print();
}
The out put is given as Magic.

I wanted to know why is it happening.
In case i add one data member to the class say int i;
then this code will not work.

Can any body explain why?

Calling a function on an invalid pointer illicits undefined behavior.

[Marcus Kwok]

ns*******@gmail .com wrote:

class A
{
public:
void print(){cout << "Magic" << endl;}
};

int main()
{
A* ptrA = NULL;
ptrA->print();
}
The out put is given as Magic.

I wanted to know why is it happening.

You have UB, which means anything can happen.

Member functions are basically regular functions with a hidden "this"
parameter, so in a situation like you gave above, it is possible that it
will work. However, if you add a data member and try to access it, then
you will almost certainly get a crash.

Do not rely on this behavior. Dereferencing a null pointer is always a
bad idea.

--
Marcus Kwok
Replace 'invalid' with 'net' to reply

[Andre Kostur]

Marcus Kwok wrote:

ns*******@gmail .com wrote:

class A
{
public:
void print(){cout << "Magic" << endl;}
};

int main()
{
A* ptrA = NULL;
ptrA->print();
}
The out put is given as Magic.

I wanted to know why is it happening.

You have UB, which means anything can happen.

Member functions are basically regular functions with a hidden "this"
parameter, so in a situation like you gave above, it is possible that it
will work. However, if you add a data member and try to access it, then
you will almost certainly get a crash.

Do not rely on this behavior. Dereferencing a null pointer is always a
bad idea.

However, could you tell us what platform and compiler this was on so
that we can easily hold it up as an example of how undefined behaviour
can blow up? (I haven't seen this particular type of undefined
behaviour fail before, unless you attempt to reference a member variable
from within the method that was called.)

[Marcus Kwok]

Andre Kostur <nn******@kostu r.net> wrote:

Marcus Kwok wrote:

ns*******@gmail .com wrote:

class A
{
public:
void print(){cout << "Magic" << endl;}
};

int main()
{
A* ptrA = NULL;
ptrA->print();
}
The out put is given as Magic.

You have UB, which means anything can happen.

Member functions are basically regular functions with a hidden "this"
parameter, so in a situation like you gave above, it is possible that it
will work. However, if you add a data member and try to access it, then
you will almost certainly get a crash.

Do not rely on this behavior. Dereferencing a null pointer is always a
bad idea.

However, could you tell us what platform and compiler this was on so
that we can easily hold it up as an example of how undefined behaviour
can blow up? (I haven't seen this particular type of undefined
behaviour fail before, unless you attempt to reference a member variable
from within the method that was called.)

Honestly, it works on all four systems I just tried it on, but that's
the problem with UB: It can do anything, including exactly what you
expect it to do. However, I will stick to my stance that relying on UB
is generally not a good idea.

--
Marcus Kwok
Replace 'invalid' with 'net' to reply

[nsharma78]

I know that it is UB. I was just curious how that function is executed
thru a NULL pointer.
It seems that this function is as good as a non-member function
executing at its own and do not require any valid pointer.

but whenever we add a data member it simply crashes.

I just wanted to know what causes that crash and why it is necessary to
add a data member to re-produce that crash.

Thanks,

Marcus Kwok wrote:

Andre Kostur <nn******@kostu r.net> wrote:

Marcus Kwok wrote:

ns*******@gmail .com wrote:
class A
{
public:
void print(){cout << "Magic" << endl;}
};

int main()
{
A* ptrA = NULL;
ptrA->print();
}
The out put is given as Magic.

You have UB, which means anything can happen.

Member functions are basically regular functions with a hidden "this"
parameter, so in a situation like you gave above, it is possible that it
will work. However, if you add a data member and try to access it, then
you will almost certainly get a crash.

Do not rely on this behavior. Dereferencing a null pointer is always a
bad idea.

However, could you tell us what platform and compiler this was on so
that we can easily hold it up as an example of how undefined behaviour
can blow up? (I haven't seen this particular type of undefined
behaviour fail before, unless you attempt to reference a member variable
from within the method that was called.)

Honestly, it works on all four systems I just tried it on, but that's
the problem with UB: It can do anything, including exactly what you
expect it to do. However, I will stick to my stance that relying on UB
is generally not a good idea.

--
Marcus Kwok
Replace 'invalid' with 'net' to reply

[Andre Kostur]

ns*******@gmail .com wrote:

I know that it is UB. I was just curious how that function is executed
thru a NULL pointer.
It seems that this function is as good as a non-member function
executing at its own and do not require any valid pointer.

but whenever we add a data member it simply crashes.
Back to my curiosity question of what platform and compiler is this?
Just so we (clc++) can use it as an example of where this specific
instance of UB crashes the program.
I just wanted to know what causes that crash and why it is necessary to
add a data member to re-produce that crash.

Not to sound snarky, but why do you care? Since attempting to call a
method through a NULL pointer invokes Undefined Behviour, regardless of
whatever the content of your class is, why does it matter when it
crashes? (I explained why _I_ want to know when this crashes....)

However, the nutshell version (and definitely implementation-specific)
is that in most cases the compiler converts function calls of the form:

obj->method(param 1, param2);

into something resembling:

method(obj, param1, param2);
Inside method(), the first parameter(obj) gets assigned to the "this"
pointer, and the rest of the parameters are dealt with as normal.

However, simply adding a member variable "shouldn't" cause anything to
blow up unless you attempt to access that variable within the method.
Up to that point you haven't (necessarily) caused the program to attempt
to dereference the NULL pointer. If you tried to access the member
variable:

a = 4;

That would be "converted" to:

this->a = 4;

This would have to dereference the NULL pointer, and attempt to assign 4
into whatever appropriate memory location relative to NULL that a
happens to lie on (and is likely not writable memory...).

And more things start coming into play if method() happens to be virtual....

Again, all of this is conjecture, and compiler implementors can
implement all of this in whatever way they choose. It all boils down
to: Calling methods through a NULL pointer is Undefined Behaviour.

[Ben C]

On 2006-04-11, ns*******@gmail .com <ns*******@gmai l.com> wrote:

[...]
class A
{
public:
void print(){cout << "Magic" << endl;}
};

int main()
{
A* ptrA = NULL;
ptrA->print();
} I know that it is UB. I was just curious how that function is executed
thru a NULL pointer. It seems that this function is as good as a non-member function
executing at its own and do not require any valid pointer.

but whenever we add a data member it simply crashes.

I just wanted to know what causes that crash and why it is necessary to
add a data member to re-produce that crash.
[...]

The function print() is non-virtual, and so the compiler doesn't need to
dereference ptrA to find the function print. It would be generating
unnecessarily inefficient code if it did. So the call to ptrA->print()
doesn't actually require dereferencing ptrA at all. It's just a call to
A::print() with the parameter 0 in "this".

Of course, as soon as you access a data member in the body of print(),
the program will access 0->data_ and that's when it'll very likely
crash.

I think it probably is defined that a class with no virtual functions
has no vtable.

Still calling a method of 0 probably is undefined behaviour anyway.

[Gavin Deane]

Ben C wrote:

I think it probably is defined that a class with no virtual functions
has no vtable.
If by "defined" you mean "required by the standard" then, no that's not
defined. The standard doesn't say anything about vtables at all. I'd be
surprised if any compiler that elected to implement polymorphism
through vtables also put a vtable in a class with no virtual functions
though.
Still calling a method of 0 probably is undefined behaviour anyway.

It's definitely undefined behaviour. Always.

Gavin Deane