From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1MU5MW-00081P-UI for mharc-grub-devel@gnu.org; Thu, 23 Jul 2009 16:58:00 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MU5MV-00081C-5p for grub-devel@gnu.org; Thu, 23 Jul 2009 16:57:59 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MU5MQ-00080c-Hm for grub-devel@gnu.org; Thu, 23 Jul 2009 16:57:58 -0400 Received: from [199.232.76.173] (port=34863 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MU5MQ-00080Y-AG for grub-devel@gnu.org; Thu, 23 Jul 2009 16:57:54 -0400 Received: from mx20.gnu.org ([199.232.41.8]:3700) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MU5MP-0008Fz-J8 for grub-devel@gnu.org; Thu, 23 Jul 2009 16:57:53 -0400 Received: from c60.cesmail.net ([216.154.195.49]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MU5MO-0004lu-Ih for grub-devel@gnu.org; Thu, 23 Jul 2009 16:57:52 -0400 Received: from unknown (HELO smtprelay2.cesmail.net) ([192.168.1.112]) by c60.cesmail.net with ESMTP; 23 Jul 2009 16:57:50 -0400 Received: from [192.168.0.22] (static-72-92-88-10.phlapa.fios.verizon.net [72.92.88.10]) by smtprelay2.cesmail.net (Postfix) with ESMTPSA id D7C0834C6A for ; Thu, 23 Jul 2009 17:08:33 -0400 (EDT) From: Pavel Roskin To: The development of GRUB 2 In-Reply-To: References: <1248347411.4660.81.camel@accesodirecto.casa> <1248359851.7855.2.camel@mj> <1248363011.4660.157.camel@accesodirecto.casa> <1248372662.4660.161.camel@accesodirecto.casa> <1248378660.2661.54.camel@mj> Content-Type: text/plain Date: Thu, 23 Jul 2009 16:57:49 -0400 Message-Id: <1248382669.2661.93.camel@mj> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 (2.26.3-1.fc11) Content-Transfer-Encoding: 7bit X-Detected-Operating-System: by mx20.gnu.org: Genre and OS details not recognized. X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 4) Subject: Re: [PATCH] Check for the appropriate condition in types.h 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: Thu, 23 Jul 2009 20:57:59 -0000 On Thu, 2009-07-23 at 22:30 +0200, Vladimir 'phcoder' Serbinenko wrote: > >> > [GRUB_CPU_SIZEOF_VOID_P == 8]: Changed to ... > >> > [GRUB_CPU_SIZEOF_LONG == 8]: ... this. > >> Ok, let's adopt this form instead. The proposed ChangeLog would now be: > > > > >From the GNU Coding Standards: > > > > "C programs often contain compile-time `#if' conditionals. Many changes > > are conditional; sometimes you add a new definition which is entirely > > contained in a conditional. It is very useful to indicate in the > > change log the conditions for which the change applies. Our convention > > for indicating conditional changes is to use square brackets around the > > name of the condition." > > > > It means that the square brackets are used if the changes only affect > > the code under the condition specified in brackets. This is not what is > > happening here. > > > This is exactly what happens here: we change only what happens in > conditionals [GRUB_CPU_SIZEOF_VOID_P == 8] and [GRUB_CPU_SIZEOF_LONG > == 8] I'm not interested to discuss the right interpretation of the coding standards. Frankly, I'm not a fan of keeping ChangeLog, as it's too formal and it's a point of contention for parallel development. I prefer the Linux kernel style of descriptions. But since we are updating ChangeLog, let's keep it readable. > >> (UINT_TO_PTR): move outside wordsize conditionals > >> (PTR_TO_UINT): new macro > > > > We should remove PTR_TO_UINT32 and PTR_TO_UINT64 with PTR_TO_UINT > > everywhere. I've checked that it doesn't introduce any warnings on any > > platform. > > > Sometimes PTR_TOUINT32 with precision loss is exactly what the coder > wants. A typical example is booting 32-bit OS on 64-bit platform. This > is the case of booting linux on efi64. Then the code has to ensure > that the target is below 4GiB (see my mm propositions for more on how > to ensure it). But I'm ok with requirement of additional explicit cast > in such cases as > (grub_uint32_t) PTR_TO_UINT (x) That would be much better that PTR_TO_UINT32, as it makes the cast explicit in the code that should ensure that the cast is valid. We can find such cases by compiling with -Wconversion and finding the newly appearing warnings after PTR_TO_UINT32 and PTR_TO_UINT64 are replaced with PTR_TO_UINT. -- Regards, Pavel Roskin