From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=37329 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OlRKC-00036Y-S1 for qemu-devel@nongnu.org; Tue, 17 Aug 2010 14:55:53 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OlRKB-0008OP-A1 for qemu-devel@nongnu.org; Tue, 17 Aug 2010 14:55:52 -0400 Received: from fe02x03-cgp.akado.ru ([77.232.31.165]:63012 helo=akado.ru) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OlRKB-0008O8-2h for qemu-devel@nongnu.org; Tue, 17 Aug 2010 14:55:51 -0400 Date: Tue, 17 Aug 2010 22:55:25 +0400 (MSD) From: malc Subject: Re: [Qemu-devel] [PATCH 2/5] CODING_STYLE: add C type rules In-Reply-To: Message-ID: References: <4C6A43B5.40809@redhat.com> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="33734824-1424011257-1282071329=:1411" List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Blue Swirl Cc: Jes Sorensen , qemu-devel This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --33734824-1424011257-1282071329=:1411 Content-Type: TEXT/PLAIN; charset=UTF-8 Content-Transfer-Encoding: 8BIT On Tue, 17 Aug 2010, Blue Swirl wrote: > On Tue, Aug 17, 2010 at 8:09 AM, Jes Sorensen wrote: > > On 08/12/10 19:50, Blue Swirl wrote: > >> +While using "bool" is good for readability, it comes with minor caveats: > >> + - Don't use "bool" in places where the type size must be constant across > >> +   all systems, like public interfaces and on-the-wire protocols. > >> + - Don't compare a bool variable against the literal, "true", > >> +   since a value with a logical non-false value need not be "1". > >> +   I.e., don't write "if (seen == true) ...".  Rather, write "if (seen)...". > > > > I'd strongly discourage the use of bool in any code. It doesn't provide > > anything guarantees and you are not sure about the size of it. Using int > > is safer. IMHO bool is one of the worse examples of changes to the C > > standard :( > > > > bool foo = false; > > foo++; > > if (foo == true).... > > It's already in use. Could you write a replacement rule which forbids > any new bool use and welcomes patches to remove any existing cases? > > > The other thing that might be worth mentioning in the int/long section > > is that long is complicated in broken development environments such as > > Windows where it is only 32 bit :( There's absolutely nothing broken about LLP64 it's as valid as any other ABI. (That's to Jes) > > Only on Win64 (http://technet.microsoft.com/en-us/library/bb496995.aspx) > but we don't support that. We "don't support" that only because nobody has merged Filip Navara's port[1] > We could add something like traditional "don't mix int and pointer > sizes" and not require intptr_t in place of longs. > [1] http://repo.or.cz/w/qemu/navara.git/commit/e777e89c4be2b80b37043e72fe6158da5ea4bf6c -- mailto:av1474@comtv.ru --33734824-1424011257-1282071329=:1411--