qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 4/4] kvm: i386: Add classic PCI device assignmen


From: Anthony Liguori
Subject: Re: [Qemu-devel] [PATCH 4/4] kvm: i386: Add classic PCI device assignment
Date: Tue, 28 Aug 2012 16:51:41 -0500
User-agent: Notmuch/0.13.2+93~ged93d79 (http://notmuchmail.org) Emacs/23.3.1 (x86_64-pc-linux-gnu)

Blue Swirl <address@hidden> writes:

> On Tue, Aug 28, 2012 at 7:31 PM, Anthony Liguori <address@hidden> wrote:
>> Blue Swirl <address@hidden> writes:
>>
>>> On Tue, Aug 28, 2012 at 5:28 PM, Michael S. Tsirkin <address@hidden> wrote:
>>>> On Tue, Aug 28, 2012 at 05:01:55PM +0000, Blue Swirl wrote:
>>>>> On Tue, Aug 28, 2012 at 7:35 AM, Michael Tokarev <address@hidden> wrote:
>>>>> > On 27.08.2012 22:56, Blue Swirl wrote:
>>>>> > []
>>>>> >>> +static uint32_t slow_bar_readb(void *opaque, target_phys_addr_t addr)
>>>>> >>> +{
>>>>> >>> +    AssignedDevRegion *d = opaque;
>>>>> >>> +    uint8_t *in = d->u.r_virtbase + addr;
>>>>> >>
>>>>> >> Don't perform arithmetic with void pointers.
>>>>> >
>>>>> > There are a few places in common qemu code which does this for a very
>>>>> > long time.  So I guess it is safe now.
>>>>>
>>>>> It's a non-standard GCC extension.
>>>>
>>>> So?  We use many other GCC extensions. grep for typeof.
>>>
>>> Dependencies should not be introduced trivially. In this case, it's
>>> pretty easy to avoid void pointer arithmetic as Jan's next version
>>> shows.
>>
>> The standard is vague with respect void arithmetic.  Most compilers
>> allow it.  A very good analysis of the standard can be found below.
>>
>> http://stackoverflow.com/questions/3523145/pointer-arithmetic-for-void-pointer-in-c
>
> The analysis would seem to show that arithmetic may be acceptable, but
> it doesn't say that void pointers must be treated like char pointers.
> In my view, this would make sense:
>
> char *cptr;
> void *vptr;
>
> Since
> cptr++;
> is equivalent to
> cptr = (char *)((uintptr_t)cptr + sizeof(*cptr));
>
> therefore
>
> vptr++;
> should be equivalent to
> vptr = (void *)((uintptr_t)vptr + sizeof(*vptr));
> That is, vptr++ should be equivalent to vptr += 0 because sizeof(void)
> should be 0 if allowed.

sizeof(void) == 1

With GCC at least.

Regards,

Anthony Liguori

>>
>> Regards,
>>
>> Anthony Liguori
>>
>>>
>>>>
>>>> Is there a work in progress to build GCC with visual studio?
>>>> If yes what are the chances KVM device assignment
>>>> will work on windows?
>>>
>>> IIRC there was really a project to use KVM on Windows and another
>>> project to build QEMU with MSVC.
>>>
>>>>
>>>> Look QEMU codebase is what it is. Unless you rework all existing
>>>> code to confirm to your taste, I do not see why you NACK valid new code
>>>> unless it confirms to same.
>>>
>>> Yes, I'd be happy to fix the style with huge patches at once. But our
>>> fearless leader does not agree, so we are stuck with the codebase
>>> being what it is until it is fixed one step at a time.
>>>
>>>>
>>>>> >
>>>>> > /mjt
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe kvm" in
>>> the body of a message to address@hidden
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html



reply via email to

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