Topic: Defect Report: does reinterpret_cast<T*>(0) yield a null pointer?
Author: francis@robinton.demon.co.uk (Francis Glassborow)
Date: Sun, 15 Feb 2004 21:32:46 +0000 (UTC) Raw View
In article <F3uXb.19485$hR.557901@bgtnsc05-news.ops.worldnet.att.net>,
Andrew Koenig <ark@acm.org> writes
>"Gennaro Prota" <gennaro_prota@yahoo.com> wrote in message
>news:ut6s20dk9n2vir774arg0a58nbr86084v7@4ax.com...
>
>> PROPOSED 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
>
>Footnotes are normative.
Not be standard ISO rules, footnotes, examples and notes are
non-normative.
--
Francis Glassborow ACCU
Author of 'You Can Do It!' see http://www.spellen.org/youcandoit
For project ideas and contributions: http://www.spellen.org/youcandoit/projects
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: gennaro_prota@yahoo.com (Gennaro Prota)
Date: Mon, 16 Feb 2004 03:26:21 +0000 (UTC) Raw View
On Sun, 15 Feb 2004 21:32:46 +0000 (UTC), francis@robinton.demon.co.uk
(Francis Glassborow) wrote:
>Not be standard ISO rules, footnotes, examples and notes are
>non-normative.
IIUC any ISO standard must conform to
http://anubis.dkuug.dk/JTC1/SC22/WG9/isodir3.pdf
However Andrew Koenig's comment worries me a bit, because it may mean
some of the authors of the C++ standard could have thought to express
a requirement whereas readers (implementers) will not consider it to
be such.
Genny.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: francis@robinton.demon.co.uk (Francis Glassborow)
Date: Mon, 16 Feb 2004 18:52:04 +0000 (UTC) Raw View
In article <c5tv209dv1t5gudd6b4pkv84k8v6mdkplv@4ax.com>, Gennaro Prota
<gennaro_prota@yahoo.com> writes
>On Sun, 15 Feb 2004 21:32:46 +0000 (UTC), francis@robinton.demon.co.uk
>(Francis Glassborow) wrote:
>
>>Not be standard ISO rules, footnotes, examples and notes are
>>non-normative.
>
>IIUC any ISO standard must conform to
>
> http://anubis.dkuug.dk/JTC1/SC22/WG9/isodir3.pdf
>
>
>However Andrew Koenig's comment worries me a bit, because it may mean
>some of the authors of the C++ standard could have thought to express
>a requirement whereas readers (implementers) will not consider it to
>be such.
I am pretty sure that Andy just misspoke because I know that he is more
familiar than most with the document at the link above.
--
Francis Glassborow ACCU
Author of 'You Can Do It!' see http://www.spellen.org/youcandoit
For project ideas and contributions: http://www.spellen.org/youcandoit/projects
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: ark@acm.org ("Andrew Koenig")
Date: Mon, 16 Feb 2004 21:09:27 +0000 (UTC) Raw View
> >Footnotes are normative.
>
> Not be standard ISO rules, footnotes, examples and notes are
> non-normative.
I'm sorry -- you're right; I misread the table in the ISO Drafting
Directives.
There's a section marked "Normative General [elements in a standard]" that
includes "footnotes" as one of those elements. However, "Footnotes"
(actually "Footnote(s)") is in italic type, and a footnote mentions that
text in italic type represents informative elements.
Which raises the question: If that information is in a footnote, isn't it
just informative?
Fortunately, the directives do answer that question, in subclause 6.5.2, in
which they say clearly that footnotes must not contain requirements. I
don't know why I missed that the first time. Sigh.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: Gennaro Prota <gennaro_prota@yahoo.com>
Date: Sat, 14 Feb 2004 16:53:17 +0000 (UTC) Raw View
[ note: Forwarded to C++ Committeel -sdc ]
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: 5.2.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 5.2.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.
PROPOSED 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.
Genny.
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: ark@acm.org ("Andrew Koenig")
Date: Sun, 15 Feb 2004 17:28:40 +0000 (UTC) Raw View
"Gennaro Prota" <gennaro_prota@yahoo.com> wrote in message
news:ut6s20dk9n2vir774arg0a58nbr86084v7@4ax.com...
> PROPOSED 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
Footnotes are normative.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]