From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=34594 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Om4Az-0003o8-SY for qemu-devel@nongnu.org; Thu, 19 Aug 2010 08:24:58 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1Om4Ay-0000Y8-DU for qemu-devel@nongnu.org; Thu, 19 Aug 2010 08:24:57 -0400 Received: from mx1.redhat.com ([209.132.183.28]:7477) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Om4Ay-0000Xi-6f for qemu-devel@nongnu.org; Thu, 19 Aug 2010 08:24:56 -0400 Message-ID: <4C6D2294.60304@redhat.com> Date: Thu, 19 Aug 2010 15:24:52 +0300 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH 2/5] CODING_STYLE: add C type rules 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> In-Reply-To: <4C6CE88C.9050100@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jes Sorensen Cc: Blue Swirl , qemu-devel , Richard Henderson 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. >>> 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. If you want to align explicitly, use alignment attributes. -- error compiling committee.c: too many arguments to function