From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1MTOrH-0002qv-IF for mharc-grub-devel@gnu.org; Tue, 21 Jul 2009 19:34:55 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MTOrG-0002qp-0r for grub-devel@gnu.org; Tue, 21 Jul 2009 19:34:54 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MTOrA-0002qX-I1 for grub-devel@gnu.org; Tue, 21 Jul 2009 19:34:52 -0400 Received: from [199.232.76.173] (port=40081 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MTOrA-0002qU-DI for grub-devel@gnu.org; Tue, 21 Jul 2009 19:34:48 -0400 Received: from mail-fx0-f223.google.com ([209.85.220.223]:36506) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MTOrA-0005CE-1J for grub-devel@gnu.org; Tue, 21 Jul 2009 19:34:48 -0400 Received: by fxm23 with SMTP id 23so1023491fxm.42 for ; Tue, 21 Jul 2009 16:34:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=3/pcqViNTvZAwaI732iddItzULXj+yyjZvpnm9+76FU=; b=K1UgYbd7A1X7OR2naZ7Na0jBgTlDWlWTxkCRilA5xLX9nwqQwYtSiXxFkRRQy7xdxx yXr7y+rmEcKS08MINa/3LUjbeUsoyjwrZFyFbZI4hdri55Eg8DqJm6s5nlRyeBRGWiOt Z6WVA5aAa346NXWwMF/svI1bzm8ZzH6pRPDdA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; b=d6pqDTHkyCYTnG3O+T0JKxqK1cgreYXrfj1+qcWzKdOcCW03dRrAz6PScMc8JpY4LB 8joDzvtkzqX0vOz0bnly2sncnCCE5c2YY+aJfBW1IPvNoL7g0pzfDmPPB8eqyAfHvit1 pgY14l+1Jsz+Anaz0rJNlVlPEfCzy/IckdJZA= Received: by 10.86.87.1 with SMTP id k1mr253259fgb.74.1248219286567; Tue, 21 Jul 2009 16:34:46 -0700 (PDT) Received: from ?192.168.1.100? (89.141.11.145.dyn.user.ono.com [89.141.11.145]) by mx.google.com with ESMTPS id d6sm16092971fga.0.2009.07.21.16.34.45 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 21 Jul 2009 16:34:45 -0700 (PDT) Message-ID: <4A663472.5090205@gmail.com> Date: Tue, 21 Jul 2009 23:34:42 +0200 From: =?ISO-8859-1?Q?Javier_Mart=EDn?= User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: The development of GRUB 2 References: <1248196443.27068.86.camel@mj> <4A660CE9.6040104@gmail.com> <1248211910.18091.8.camel@mj> <1248213902.18091.20.camel@mj> <4A66218A.3020506@gmail.com> <1248215855.18091.32.camel@mj> In-Reply-To: <1248215855.18091.32.camel@mj> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) Subject: Re: [PATCH] UUID support for UFS X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2009 23:34:54 -0000 Pavel Roskin escribió: > On Tue, 2009-07-21 at 22:14 +0200, Javier Martín wrote: > >>> But I would prefer that we work on fixing bugs rather than non-bugs. >>> >> "Fixing" this would allow us to have cleaner code, and separate "casual >> variables" from fixed-length variables. If we print int with %d and >> int32_t with PRId32, the impact of the subtle bugs that appear when we >> port across architectures will be reduced. > > If int and int32_t are different types, gcc will warn about it, at least > for implicit conversion with data loss. Oh, yes... with the current build system and without -Werror, warnings are _very_ visible. Besides, do we really have -Wconversion enabled? I don't know, but gcc tends to be quite silent when it comes to type conversion, mainly due to the laxitude it's used in *nix C programs. The cast in that code was all but implicit, and explicit casts tend to shut the compiler up. > > It's more likely that bugs will be introduced by that change, not fixed. > Besides, the code will be harder to read. You say it'd be harder to read because the macros are newly-introduced (C99) and thus not widely know. However, they are pretty clear and self-explanatory once you google them the first time... and at the very least they call attention to themselves: an unknowing programmer would wonder what they are. Using a "normal" print specifier and a type cast does not.