Null references.

[jason.cipriani]

Is it OK to dereference NULL pointers if the only thing you are doing
is storing them in a reference then comparing addresses to NULL again
later, as in:

=== BEGIN EXAMPLE ===

Something g_something;

const Something & getSomething () {
if (condition)
return g_something;
else
return *(const Something *)NULL; // <--- !!!
}

void function () {
const Something &s = getSomething;
if (&s == NULL) { // <--- !!!
// ...
} else {
// ...
}
}

=== END EXAMPLE ===

Thanks,
Jason

[Sam]

ja************@ gmail.com writes:

Is it OK to dereference NULL pointers if the only thing you are doing
is storing them in a reference then comparing addresses to NULL again
later, as in:

Well, it or may not be legal. But, doing that is like dressing up like a
Santa Claus and walking past a hungry bull. It's not advisable.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEABECAAYFAkh 9WuoACgkQx9p3GY HlUOL0pwCfc7HdL KZK9k5Y3kv4zHvg APC/
4AQAnRX+YJPQTD9 kr3sgONXqjCwBka cQ
=Ykj2
-----END PGP SIGNATURE-----

[jason.cipriani]

On Jul 15, 10:32 pm, "Alf P. Steinbach" <[e-mail] wrote:

* jason.cipri...@ gmail.com:

Is it OK to dereference NULL pointers if the only thing you are doing
is storing them in a reference then comparing addresses to NULL again
later

No.

That incurs Undefined Behavior.

Then, if this is undefined:

Something &ref = *(Something &)NULL;

Doesn't that mean this also undefined?

Something *ptr = NULL;
Something &ref = *ptr;

And if so, then that also means this is undefined, as the possibility
exists for the pointer to be NULL?

Something * function ();
Something *ptr = function();
Something &ref = *ptr;

And if that is undefined, is this the cleanest way to make sure
nothing undefined happens?

Something * function ();
Something *ptr = function();
if (ptr) {
Something &ref = *ptr;
// ...
} else {
// error
}

Also, unrelated to references, just out of curiosity, does that mean
statements like this are also undefined:

Something *ptr = &(*(Somethin g *)NULL);

Thanks,
Jason

[jason.cipriani]

On Jul 15, 10:49 pm, "jason.cipri... @gmail.com"
<jason.cipri... @gmail.comwrote :

Then, if this is undefined:

Something &ref = *(Something &)NULL;

I'm sorry this should read:

Something &ref = *(Something *)NULL;

Jason

[jason.cipriani]

On Jul 15, 11:04 pm, "Alf P. Steinbach" <[e-mail] wrote:

Depends on whether the pointer actually can be 0. It's the actual dereferencing
of a nullpointer that incurs Undefined Behavior. Not the potential.

Oh, I guess that makes sense.

Thanks for the good response and explanation.

Jason

[James Kanze]

On Jul 16, 5:04 am, "Alf P. Steinbach" <[e-mail] wrote:

There are some exceptions to incurring UB for dereferencing a
nullpointer. The most important one is that any given compiler
vendor can decide to give that a well-defined meaning at
compile time for that compiler, and exploit that to implement
various macros in the standard library. Another one is the
context of a typeid call.

Hows that?

Modulo vendor specific guarantees (of course), it's undefined
behavior to dereference a null pointer in code that actually
gets executed. Something like sizeof( *p ) is fine, even if p
is a null pointer. But typeid normally requires execution,
e.g.: typeid( *p ) is undefined behavior if p is a null pointer
(and the pointed to object has a polymorphic type, but then,
that's the usual reason for using typeid).

--
James Kanze (GABI Software) email:ja******* **@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientier ter Datenverarbeitu ng
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[James Kanze]

On Jul 16, 1:28 pm, "Alf P. Steinbach" <[e-mail] wrote:

* James Kanze:

On Jul 16, 5:04 am, "Alf P. Steinbach" <[e-mail] wrote:

There are some exceptions to incurring UB for dereferencing a
nullpointer. The most important one is that any given compiler
vendor can decide to give that a well-defined meaning at
compile time for that compiler, and exploit that to implement
various macros in the standard library. Another one is the
context of a typeid call.

Hows that?

Modulo vendor specific guarantees (of course), it's undefined
behavior to dereference a null pointer in code that actually
gets executed. Something like sizeof( *p ) is fine, even if p
is a null pointer. But typeid normally requires execution,
e.g.: typeid( *p ) is undefined behavior if p is a null pointer
(and the pointed to object has a polymorphic type, but then,
that's the usual reason for using typeid).

I'm sorry, that's incorrect. §5.2.8/2, typeid guarantees to
throw a std::bad_typeid exception if you give it an lvalue
formed by dereferencing a nullpointer to polymorphic type. So
we're out of UB-land and into guaranteed exception-land. :-)

Interesting. A bit strange, but who's to complain. Anything
which reduces undefined behavior is good.

--
James Kanze (GABI Software) email:ja******* **@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientier ter Datenverarbeitu ng
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]