Title
reinterpret_cast<T*>(0)
Status
cd1
Section
7.6.1.10 [expr.reinterpret.cast]
Submitter
Gennaro Prota

Created on 2004-02-14.00:00:00 last changed 197 months ago

Messages

Date: 2006-04-15.00:00:00

[Voted into WP at April, 2006 meeting.]

Date: 2005-04-15.00:00:00

Proposed resolution (April, 2005):

  1. Delete the footnote in 7.6.1.10 [expr.reinterpret.cast] paragraph 5 reading,

    Converting an integral constant expression (7.7 [expr.const]) with value zero always yields a null pointer (7.3.12 [conv.ptr]), but converting other expressions that happen to have value zero need not yield a null pointer.
  2. Add the indicated note to 7.6.1.10 [expr.reinterpret.cast] paragraph 8:

    The null pointer value (7.3.12 [conv.ptr]) is converted to the null pointer value of the destination type. [Note: A null pointer constant, which has integral type, is not necessarily converted to a null pointer value. —end note]
Date: 2004-10-15.00:00:00

Notes from October 2004 meeting:

This footnote was added in 1996, after the invention of reinterpret_cast, so the presumption must be that it was intentional. At this time, however, the CWG feels that there is no reason to require that reinterpret_cast<T*>(0) produce a null pointer value as its result.

Date: 2004-02-14.00:00:00

Is reinterpret_cast<T*>(null_pointer_constant) guaranteed to yield the null pointer value of type T*?

I think a committee clarification is needed. Here's why: 7.6.1.10 [expr.reinterpret.cast] par. 8 talks of "null pointer value", not "null pointer constant", so it would seem that

  reinterpret_cast<T*>(0)
is a normal int->T* conversion, with an implementation-defined result.

However a little note to 7.6.1.10 [expr.reinterpret.cast] par. 5 says:

Converting an integral constant expression (5.19) with value zero always yields a null pointer (4.10), but converting other expressions that happen to have value zero need not yield a null pointer.
Where is this supported in normative text? It seems that either the footnote or paragraph 8 doesn't reflect the intent.

SUGGESTED RESOLUTION: I think it would be better to drop the footnote #64 (and thus the special case for ICEs), for two reasons:

a) it's not normative anyway; so I doubt anyone is relying on the guarantee it hints at, unless that guarantee is given elsewhere in a normative part

b) users expect reinterpret_casts to be almost always implementation dependent, so this special case is a surprise. After all, if one wants a null pointer there's static_cast. And if one wants reinterpret_cast semantics the special case requires doing some explicit cheat, such as using a non-const variable as intermediary:

   int v = 0;
   reinterpret_cast<T*>(v); // implementation defined

   reinterpret_cast<T*>(0); // null pointer value of type T*
   const int w = 0;
   reinterpret_cast<T*>(w); // null pointer value of type T*

It seems that not only that's providing a duplicate functionality, but also at the cost to hide what seems the more natural one.

History
Date User Action Args
2008-10-05 00:00:00adminsetstatus: wp -> cd1
2006-11-05 00:00:00adminsetstatus: dr -> wp
2006-04-22 00:00:00adminsetmessages: + msg1363
2006-04-22 00:00:00adminsetstatus: ready -> dr
2005-10-22 00:00:00adminsetstatus: review -> ready
2005-05-01 00:00:00adminsetmessages: + msg1144
2005-05-01 00:00:00adminsetstatus: drafting -> review
2004-11-07 00:00:00adminsetmessages: + msg1077
2004-11-07 00:00:00adminsetstatus: open -> drafting
2004-02-14 00:00:00admincreate