From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:51603) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WJ39V-00057l-9z for qemu-devel@nongnu.org; Thu, 27 Feb 2014 10:45:43 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WJ39P-0004ER-Aq for qemu-devel@nongnu.org; Thu, 27 Feb 2014 10:45:37 -0500 Received: from mx1.redhat.com ([209.132.183.28]:1700) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WJ39O-0004E5-Sf for qemu-devel@nongnu.org; Thu, 27 Feb 2014 10:45:31 -0500 Date: Thu, 27 Feb 2014 16:45:22 +0100 From: Stefan Hajnoczi Message-ID: <20140227154522.GF30987@stefanha-thinkpad.redhat.com> References: <1393174935-11750-1-git-send-email-sw@weilnetz.de> <1393174935-11750-10-git-send-email-sw@weilnetz.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1393174935-11750-10-git-send-email-sw@weilnetz.de> Subject: Re: [Qemu-devel] [PATCH 9/9] w32: Replace Windows specific data types in common header files List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Weil Cc: Kevin Wolf , Peter Maydell , qemu-devel@nongnu.org, Anthony Liguori On Sun, Feb 23, 2014 at 06:02:15PM +0100, Stefan Weil wrote: > These header files are used by most QEMU source files. If they > depend on windows.h, all those source files do so, too. > > All Windows specific data types which are replaced use identical > definitions for the 32 and 64 bit Windows APIs. HANDLE and LONG > can be directly replaced by void * and long. CRITICAL_SECTION > is replaced by a new struct of the same size. Can you use a typedef? When I read code that uses HANDLE, I immediately know this is Windows and which sorts of APIs can accept this HANDLE value. Now when I see void * it's just an opaque C type. We've lost information :(. /* Since windows.h drags in a lot of headers, we define equivalent * typedefs for some core Win32 types. */ typedef void *QEMU_WIN32_HANDLE; /* is there a more concise name? */ ... Stefan