Re: [PATCH] Check for the appropriate condition in types.h

[Pavel Roskin <proski@gnu.org>]

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