From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Nyqc4-0004of-HJ for qemu-devel@nongnu.org; Mon, 05 Apr 2010 14:01:28 -0400 Received: from [140.186.70.92] (port=40151 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Nyqc2-0004nV-KT for qemu-devel@nongnu.org; Mon, 05 Apr 2010 14:01:27 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1Nyqc0-0004Fq-RI for qemu-devel@nongnu.org; Mon, 05 Apr 2010 14:01:26 -0400 Received: from moutng.kundenserver.de ([212.227.17.9]:62083) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Nyqbx-0004F5-Nu for qemu-devel@nongnu.org; Mon, 05 Apr 2010 14:01:24 -0400 Message-ID: <4BBA256C.8060206@mail.berlios.de> Date: Mon, 05 Apr 2010 20:01:16 +0200 From: Stefan Weil MIME-Version: 1.0 References: <1270158985-13119-1-git-send-email-weil@mail.berlios.de> <20100404085951.GB3189@redhat.com> In-Reply-To: <20100404085951.GB3189@redhat.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Subject: [Qemu-devel] Re: [PATCH] win32: Fix compiler errors from u_int64_t List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Michael S. Tsirkin" Cc: Anthony Liguori , QEMU Developers Michael S. Tsirkin schrieb: > On Thu, Apr 01, 2010 at 11:56:25PM +0200, Stefan Weil wrote: >> u_int64_t raises compiler error messages: >> >> CC libhw32/virtio.o >> /qemu/ar7/hw/virtio.c: In function ‘virtio_queue_get_avail_size’: >> /qemu/ar7/hw/virtio.c:776: error: ‘u_int64_t’ undeclared (first use >> in this function) >> /qemu/ar7/hw/virtio.c:776: error: (Each undeclared identifier is >> reported only once >> /qemu/ar7/hw/virtio.c:776: error: for each function it appears in.) >> >> Replacing u_int64_t by uint64_t helps. >> >> Cc: Michael S. Tsirkin >> Cc: Anthony Liguori >> Signed-off-by: Stefan Weil > > Acked-by: Michael S. Tsirkin > > Speaking of which, we have: > /scm/qemu/slirp/slirp.h:typedef uint64_t u_int64_t; > > which we probably don't need either? Right. I'd even prefer replacing all those u_int#_t types by the standard types uint#_t. Is that ok, or would you prefer not to touch the slirp code (which makes heavy use of those types)? Regards, Stefan