Re: Null reference
* David W:
I'm almost tearing my hair out. A colleague claimed that a null reference can exist, like
this:
void f( int& p )
{
printf( "%d\n", p );
}
int main (int argc, char *argv[])
{
int*p= NULL;
f( *p );
return 0;
}
I pointed him to the relevant part of the C++ standard that forbids this in a well-defined
program, but he countered that in the "real world" a reference can be "null". An argument
then ensued in which he managed to raise concerns with two other colleagues because the
crash in the above code is likely to occur where the reference is used, which could be
anywhere, not where the null pointer is dereferenced. One (who has had little experience
with C++) even said that references "shouldn't be used in safety critical code". The other
became concerned because he'd always assumed that a reference has to refer to a valid
object, and now he wonders whether he should test for a "null reference", at least with an
assert, wherever a function takes a reference parameter.
I've tried everything I can think of to return to some sanity, but to no avail. I've told
them:
- That the problem in the code above is not the reference but the dereference of a null
pointer, which is a normal bug that everyone knows to avoid.
- That I can't recall actually coming across a "null reference" bug in a real program in
over a decade of using C++
- That there are a million things you can do that can cause undefined behaviour, so why be
specifically concerned about this one?
- That there are a multitude of ways that a bug can manifest itself long after the code
that caused it executes (e.g., keep a pointer to an object that is subsequently deleted),
so why be specifically concerned about this one?
They are still not convinced that the "null reference" is not a potential problem that
deserves some attention, and I'm looking for ideas as to what else I can say to get it off
the radar completely, where it belongs (that's if the people here agree with me of
course).
It's formally undefined behavior to dereference a nullpointer.
But it can happen, and the result of using that reference is that Bad
Things Happen.
Another way to obtain an invalid reference is to destroy an object that
some other part of the code holds a reference to (the simplest way to do
this is to return a reference to a local variable), which yields a
dangling reference.
References don't buy you technical safety: null-references and dangling
references can exist -- but null-references can't exist in a valid
program, and dangling references can't be used in a valid program.
Instead of technical safety references buy you simplicity and clear
/communication of intent/, i.e. this is intended to never be null, plus
the possibility of unified notation (e.g. indexing, which can be applied
in template code), all which in turn buys you safety and productivity.
When your function is passed a null-reference or dangling reference you
know that it's an error in the calling code. When a null-pointer or
dangling pointer occurs you don't necessarily know that it's an error in
the calling code. Perhaps you need to handle null-pointers (and the
result is messy checking and deciding what to do or not in that case,
which complicates things, and leads to more of the same, more bugs).
Summing up, your first colleague was right that null-references can
exist, but not that they can exist in a valid program. And you were
right that that situation almost never occurs in practice. Because
apart from simpler notation, the point of a reference is to communicate
that it's intended to never be null or otherwise invalid, so nobody will
try to set it to null-reference.
Your colleague who maintained that references shouldn't be used in
safety-critical code got it exactly backwards.
--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?