From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:39896) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T6ThM-0004X6-7Y for qemu-devel@nongnu.org; Tue, 28 Aug 2012 17:51:49 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1T6ThK-0002ja-Nw for qemu-devel@nongnu.org; Tue, 28 Aug 2012 17:51:48 -0400 Received: from mail-ob0-f173.google.com ([209.85.214.173]:54311) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T6ThK-0002jP-Im for qemu-devel@nongnu.org; Tue, 28 Aug 2012 17:51:46 -0400 Received: by obbta14 with SMTP id ta14so10768382obb.4 for ; Tue, 28 Aug 2012 14:51:45 -0700 (PDT) From: Anthony Liguori In-Reply-To: References: <825e653c9cfe9d8e26185917cbe1f1dd7ae299e2.1346048917.git.jan.kiszka@web.de> <503C74DD.3020307@msgid.tls.msk.ru> <20120828172838.GD3661@redhat.com> <87fw76ak5l.fsf@codemonkey.ws> Date: Tue, 28 Aug 2012 16:51:41 -0500 Message-ID: <87d32a3csy.fsf@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [Qemu-devel] [PATCH 4/4] kvm: i386: Add classic PCI device assignment List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Blue Swirl Cc: kvm@vger.kernel.org, "Michael S. Tsirkin" , Marcelo Tosatti , Michael Tokarev , qemu-devel@nongnu.org, Alex Williamson , Jan Kiszka , Avi Kivity Blue Swirl writes: > On Tue, Aug 28, 2012 at 7:31 PM, Anthony Liguori wrote: >> Blue Swirl writes: >> >>> On Tue, Aug 28, 2012 at 5:28 PM, Michael S. Tsirkin 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 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 majordomo@vger.kernel.org >>> More majordomo info at http://vger.kernel.org/majordomo-info.html