From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=49523 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Om4c8-0002tm-Dg for qemu-devel@nongnu.org; Thu, 19 Aug 2010 08:53:01 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1Om4c6-0004kL-Of for qemu-devel@nongnu.org; Thu, 19 Aug 2010 08:53:00 -0400 Received: from fe02x03-cgp.akado.ru ([77.232.31.165]:60122 helo=akado.ru) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Om4c6-0004k6-EI for qemu-devel@nongnu.org; Thu, 19 Aug 2010 08:52:58 -0400 Date: Thu, 19 Aug 2010 16:52:19 +0400 (MSD) From: malc Subject: Re: [Qemu-devel] [PATCH 2/5] CODING_STYLE: add C type rules In-Reply-To: <4C6D2294.60304@redhat.com> Message-ID: References: <4C6A43B5.40809@redhat.com> <4C6AD744.1070009@twiddle.net> <4C6ADFED.5020703@redhat.com> <4C6C0E4D.6040607@redhat.com> <4C6CE416.1050902@redhat.com> <4C6CE6F4.20804@redhat.com> <4C6CE88C.9050100@redhat.com> <4C6D2294.60304@redhat.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: Blue Swirl , Jes Sorensen , qemu-devel , Richard Henderson On Thu, 19 Aug 2010, Avi Kivity wrote: > On 08/19/2010 11:17 AM, Jes Sorensen wrote: > > On 08/19/10 10:10, Avi Kivity wrote: > > > On 08/19/2010 10:58 AM, Jes Sorensen wrote: > > > > > In C99, bool is a real type. > > > > Kinda real, I would qualify it more as a pseudo type. It doesn't map to > > > > any register size or even instruction actions. > > > Neither do int, short, long, long long, or signed short long float. > > Well most processors support 32 bit register ops, even when running in > > 64 bit mode. > > 8-bit processors have 8-bit register size and 16-bit ints. Some processors > have 36-bit ints. If you only code for processors which have Linux ports, and > for those ports, then everything will be the same. Surprise! > > > long is the maximum register size in pretty much any sane > > setup, > > Not on those 8-bit machines. > > > which is why it is such a mess that M$ took the easy way out when > > they picked for win64. Tons of user code will have portability problems > > because of this. > > They did that to avoid portability problems, presumably. http://blogs.msdn.com/b/oldnewthing/archive/2005/01/31/363790.aspx > > > > > Most processors, at least > > > > the ones I have programmed, tend to treat it as zero == false, > > > > everything else == true. > > > Processors don't have _Bool. > > No but something has to generate code to handle it. > > gcc > > > > > For structure packing it's ugly. > > > Use uint*_t for externally visible structures. use _Bool for internal > > > booleans. > > Structure packing is more than passing structures to external processes > > or saving them, it's also cache line alignment. In your case we should > > change pretty much any data structure in QEMU that is in a critical data > > path to use *int*_t. > > Not at all, _Bool is smaller or equal to int and thus can only improve > packing. That's not what standard says: 6.2.5#2 An object declared as type _Bool is large enough to store the values 0 and It later goes on to say (6.7.2.1 fn120): While the number of bits in a _Bool object is at least CHAR_BIT, the width (number of sign and value bits) of a _Bool may be just 1 bit. > > If you want to align explicitly, use alignment attributes. > > -- mailto:av1474@comtv.ru