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

[Markus Armbruster]

Anthony Liguori <address@hidden> writes:

> 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
>
> BTW: can we please stop arguing about C standards.  If we currently are
> using something in QEMU that's supported by clang and GCC, it's fine and
> we ought to continue using it.

Seconded.

I don't see a point in making contributors avoid non-problems that might
conceivably become trivial problems some day.  Especially when there's
no automated help with the avoiding.

[...]