Kevin Wolf <kw...@redhat.com> writes:
> Am 24.02.2011 08:21, schrieb Markus Armbruster:
>> Stefan Weil <w...@mail.berlios.de> 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 <w...@mail.berlios.de>
>>> ---
>>> 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.
