Kevin Wolf <address@hidden> writes:
Am 24.02.2011 08:21, schrieb Markus Armbruster:
Stefan Weil <address@hidden> writes:
Here the int values fds[0], sigfd, s, sock and fd are converted
to void pointers which are later converted back to an int value.
These conversions should always use intptr_t instead of unsigned long.
They are needed for environments where sizeof(long) != sizeof(void *).
To be precise: when you want to cast a pointer to a signed integer type
and back without loss, intptr_t is the signed integer type to use.
But here we're dealing with the opposite case: cast int to pointer and
back.
Signed-off-by: Stefan Weil <address@hidden>
---
cpus.c | 8 ++++----
migration-tcp.c | 4 ++--
migration-unix.c | 4 ++--
qemu-char.c | 4 ++--
4 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/cpus.c b/cpus.c
index 0f33945..3c4e1b8 100644
--- a/cpus.c
+++ b/cpus.c
@@ -267,7 +267,7 @@ static void qemu_event_increment(void)
static void qemu_event_read(void *opaque)
{
- int fd = (unsigned long)opaque;
+ int fd = (intptr_t)opaque;
ssize_t len;
char buffer[512];
Why can't you cast straight to int?
You would get warnings about a pointer being cast to an integer of
different size
Fair enough. Stop reading here unless you like language-lawyering ;)
(the behaviour is undefined if the integer is too small).
Correct (I looked it up). The detour via intptr_t makes it
implementation-defined.
I think you might also get a warning for the opposite direction.
Implementation-defined.
The standard defines semantics of valid void * -> intptr_t, uintptr_t ->
void *: you get your original pointer back ("will compare equal").
The standard is silent on converting integer type to pointer type and
back. Doesn't matter. No sane implementation screws that up.