Anthony Liguori <anthony@xxxxxxxxxxxxx> writes:
> Blue Swirl <blauwirbel@xxxxxxxxx> writes:
>
>> On Tue, Aug 28, 2012 at 5:28 PM, Michael S. Tsirkin <mst@xxxxxxxxxx> 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 <mjt@xxxxxxxxxx> 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.
[...]
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
