qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH] Fix conversions from pointer to int and vice ve


From: Markus Armbruster
Subject: Re: [Qemu-devel] [PATCH] Fix conversions from pointer to int and vice versa
Date: Thu, 24 Feb 2011 11:11:59 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux)

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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]