PATCH: don't sign-extend pointers when casting to unsigned long long

[Matt Austern <austern at apple dot com>]

Suppose you're on a system where pointers are 32-bit and long long is 
64-bit,
and suppose you write "unsigned long long n  = (unsigned long long) p". 
 The
results are counterintuitive.  I would expect that the high 32 bits 
would all be 0.
As it stands now, that may or may not be true: pointers get 
sign-extended.

This is perhaps a minor nit, since (a) the compiler will warn you if 
you cast a
pointer to an integer of the wrong size; (b) neither the C nor the C++ 
standard
says what happens when you cast a pointer to an integer; and (c) you 
can work
around this problem by casting to the exact unsigned type first and 
then casting
again to unsigned long long.  Despite all of those points, however, I 
still think
this ought to be fixed.  We shouldn't be doing gratuitously unintuitive 
things,
even when users are writing technically nonportable code.

Here's a patch; test case is included.  Note that the test case assumes 
that
sizeof(long long) >= sizeof(void*).  Note also that (a) I'm only 
modifying the C
and C++ front ends; and (b) I'm only  modifying the behavior of 
explicit cast
expressions, as opposed to any other conversions that the compiler 
generates
internally.

Testing: applied to mainline on Linux/i686, bootstrapped (with
--enable-languages=c++), verified that there were no dg regressions and 
that
the original test case was in fact fixed.

OK to commit?

			--Matt

Attachment: pp-fsf.txt
Description: Text document