Re: Semantic issue: "undefined behavior"
On Oct 6, 12:23 am, int...@gmail.com wrote:
On 6 Oct, 00:00, Alan McKenney <alan_mckenn...@yahoo.com> wrote:
<snip>
But casting from
pointer to "signed int" to a pointer to "unsigned int",
though perhaps "undefined", is likely to reliably work as expected.
Try that on Win64 (or any other LLP model, for that matter).
Are you saying that on Win64:
unsigned int f( int *p )
{
unsigned int *q = reinterpret_cast<unsigned int *>(p);
return *q;
}
will not return the bits of *p interpreted as unsigned int?
And does this apply to other integral types? And what, exactly
_does_ it do?
(We cast "const char *" to "const unsigned char *" and back a lot;
but we don't use MicroSloth compilers.)
This is exactly the sort of information that gives the phrase
"undefined behavior" teeth. And educates even us old-timers
in the myriad ways in which implementations can differ from
how we might expect them to be done.
And there are constructs that are somewhere in between,
such as "i++ + i++", which is not catastrophic, but may not
behave as you expect.
The problem is not that they behave not as one expects.
The problem is that they can behave differently on
different platforms, and even on different lines of
the same program!
Quite right!
Actually this is an example which, when it comes up
(as it does every 3--6 months), is usually discussed
pretty well here, in the sense of my original post.
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]