This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
C++ reinterpret_cast between pointers and integral types
- To: gcc at gcc dot gnu dot org
- Subject: C++ reinterpret_cast between pointers and integral types
- From: "Kaveh R. Ghazi" <ghazi at caip dot rutgers dot edu>
- Date: Sun, 10 Jun 2001 08:55:05 -0400 (EDT)
So I was looking in cp/typeck.c:build_reinterpret_cast() and noticed
this bit:
> if (TYPE_PTR_P (type) && (TREE_CODE (intype) == INTEGER_TYPE
> || TREE_CODE (intype) == ENUMERAL_TYPE))
> /* OK */;
> else if (TREE_CODE (type) == INTEGER_TYPE && TYPE_PTR_P (intype))
> {
> if (TYPE_PRECISION (type) < TYPE_PRECISION (intype))
> cp_pedwarn ("reinterpret_cast from `%T' to `%T' loses precision",
> intype, type);
> }
> else ...
For reference assume I'm trying to compile the following code:
void *p1 = reinterpret_cast<void*>(~0LL);
void *p2 = reinterpret_cast<void*>(~0);
void *p3 = reinterpret_cast<void*>(~(enum e)0);
void *p4 = reinterpret_cast<void*>(false);
int i1 = reinterpret_cast<int>((void*)0);
enum e e1 = reinterpret_cast<enum e>((void*)0);
char c1 = reinterpret_cast<char>((void*)0);
bool b1 = reinterpret_cast<bool>((void*)0);
My questions are:
Should the first clause use INTEGRAL_TYPE_P?
That would allow compiling p4.
Should the first clause warn about lost precision too?
E.g. p1 on 32bit pointer targets.
Should the second clause use INTEGRAL_TYPE_P?
That would allow compiling e1 and b1.
If the answers are yes, I can send a patch. Otherwise, I'd like to
add comments to the code explaining why.
Thanks,
--Kaveh
--
Kaveh R. Ghazi Engagement Manager / Project Services
ghazi@caip.rutgers.edu Qwest Internet Solutions