Dereferencing NULL pointer

[ovidiucucu]

One of often asked questions at C++ interviews is:
Whithout modifying the A class, what can be done to call its 'sum' method?

class A
{
private:
   A() {}
public:
   int sum(int i, int j) {return i + j;}
}

The simple answer I know is

   A* p = NULL;
   int s = p->sum(666, 777);

Is any problem with this answer?

[superbonzo]

do you mean "int sum(int i, int j) {return i + j;}", don't you ?

if this is the case, clearly, dereferencing a null pointer gives undefined behavior in general, although on most implementations that code would work as expected. So, I would say that the answer is (partially) accetable only if it's made clear when such code happens to work as expected ( ie, when a compiler strictly treats member function call as an ordinary function call with an implicit this pointer parameter with usual conversions ).

[Alex F]

I see the problems in the question, and not in the answer:
1) sum must return int - of course, this is just typo, like missing ; after class definition
2) good programming style requires to declare sum as static, since it doesn't use any instance class member, in this case the question doesn't make sense.

Regarding the answer - I don't see any problem, it just works.

[superbonzo]

Regarding the answer - I don't see any problem, it just works.

so, you're saying that the standard guarantees that code to work ? if yes, why ?

BTW, IMHO a better answer could be

struct { char _[ sizeof(A) ]; } pseudoA;

A*  p = reinterpret_cast<A*>( &pseudoA );
int s = p->sum(666, 777);

given that A is a POD and that A's ctor has no side effects the above should not give UB in general.

EDIT: the code above is wrong, because A is not a POD, sorry

[ovidiucucu]

Sorry, it was a typo. A::sum returns int and not void.

[Alex F]

so, you're saying that the standard guarantees that code to work ? if yes, why ?

I expected the war posting this! Well, AFAIK, standard doesn't guarantee this.
BTW, your answer looks smart (and works), but why do you think that it is standard-compliant?
Saturday war continues

[ovidiucucu]

struct { char _[ sizeof(A) ]; } pseudoA;

A*  p = reinterpret_cast<A*>( &pseudoA );
int s = p->sum(666, 777);

given that A is a POD and that A's ctor has no side effects the above should not give UB in general.

Well, even in this case we have something (according to The Holy Standard) which looks like

   int s = (*(p)).sum(666, 777);

We just have dereferenced a NULL pointer.
Genarally, is it any problem?

[superbonzo]

We just have deferenciated a NULL pointer.

no, note that pseudoA is an object not a type ( sorry for the code obfuscation ) ...

[...] but why do you think that it is standard-compliant?

well, the problem is to prove that given the assumptions of my code above ( in particular that A and pseudoA are both PODs ) sizeof(A) == sizeof(pseudoA), share the same alignment requirements and p points to a valid A instance. I don't have the standard at my disposal at the moment but I'm quite positive that putting together the wordings on POD objects memory representation and reinterpret_cast rules you could prove it.

All The Glory To The Holy Standard ! All The Glory To The Holy Standard ! ...

[TheGreatCthulhu]

I see the problems in the question, and not in the answer

I totally agree here - but, of course, the issue is: how to properly answer such a question. So, basically you can give an answer like the one proposed in the original post, as long as you point out the problems associated with it as well: (1) as someone here already said - implementation-wise, generally speaking it may or may not work, and (2) from a logical design perspective it's a bad practice, as it utterly violates the OO principles related to class design.

This way, the interviewee can show both his/hers technical insight into the nuts and bolts of the language and his/hers high-level understanding of classes and OOP.

However, IMHO, this question shouldn't be a part of the interview at all (given the problems discussed in this thread, all of which essentially stem from the question itself) - there are much more important questions that could (and should) be asked instead.

[ovidiucucu]

Well let's say that at the interview we are answering: "You are stupid, dude! according to good common sense A::sum, has to be static... Where is that door?"
However, if someone else gives another one:

class A
{
private:
   int* m;
public:
   int* getSafeM() {return (this == NULL) ? NULL : m;}
}

Is it OK or not to call A::getSafeM through an (A*) NULL pointer?

[ovidiucucu]

Well that's not a quiz, and let me detail to avoid cheasing the own tail...

Someone has told: "to call a non-static member function it's obviously necessary to have an object".

I said, "generally that's not true" and gave the above example(s).
His last argument was: "No, it's not OK what you are doing because dereferencing a NULL pointer leads in undefined behavior".

Is it true or not?

// NOTE: sorry for the initial typo: the title is "Dereferencing...".

[superbonzo]

Is it true or not?

yes it is:

[...] [Note: in particular, a null reference cannot exist in a well-defined program, because the only way to create such a reference would be to bind it to the “object” obtained by dereferencing a null pointer, which causes undefined behavior [...]

[TheGreatCthulhu]

Well let's say that at the interview we are answering: "You are stupid, dude! according to good common sense A::sum, has to be static... Where is that door?"

LOL. Well, there are more polite ways to say that (something akin to what I wrote in my previous post), with a 50/50 chance you won't be needing the (metaphorical) door. (You still might need the physical one.)

However, if someone else gives another one:

class A
{
private:
   int* m;
public:
   int* getSafeM() {return (this == NULL) ? NULL : m;}
}

Is it OK or not to call A::getSafeM through an (A*) NULL pointer?

Well, that depends on how you define "OK".
For me, it is the logical structure that primary defines a system, not it's technical aspects and/or implementation details. So, regardless of whether calling getSafeM() through a NULL pointer is legal or not, and with all due respect to all the precautions the function provides (and even if The Standard said it's OK), to me it looks like a bad design decision (in the sense that it indicates that the method was planned to potentially be called through a NULL pt).
Furthermore, if you think about it, it's a non-standard behavior as far as the idea of classes (as it exists in most of our heads) is concerned - so whoever is using the code might be a bit surprised. So, why is this useful?
Then, if you take that possibility into consideration, then every function would need to be take similar precautions.

From that standpoint, I'd categorically say NO.

But, if I was shown an example of this being useful or beneficial enough, or even required, I'd probably be willing to bend my view of what classes are a bit. I understand that other people may have different views, and I respect that; I just hope that I was able to properly express how I backup my own.

[ovidiucucu]

yes it is:

[...] [Note: in particular, a null reference cannot exist in a well-defined program, because the only way to create such a reference would be to bind it to the “object” obtained by dereferencing a null pointer, which causes undefined behavior [...]

Sounds good, but that refers to (NULL) references and not to dereferencing (NULL) pointers.

[superbonzo]

I think it refers to the latter instead . Anyway, here is another quote:

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

BTW, note that the expression "a->b" is by definition equivalent to "(*(a)).b", so I don't think there are doubts corcening the illegality of null pointer dereferencing.