Re: gcc bug causes parted to write bad GPT entries

[Richard Hirst]

On Sat, Mar 16, 2002 at 09:15:47AM +1100, Andrew Clausen wrote:
> On Fri, Mar 15, 2002 at 09:56:45PM +0000, Richard Hirst wrote:
> > The proposed work-around for the compiler bug is to redefine efi_guid_t
> > to be an array of 16 bytes, rather than a packed struct.  That approach
> > is favoured by David Mosberger and Matt Domsch anyway, to avoid byte
> > ordering issues.
> 
> Is there any reason to not require gcc 3.1?

Both RedHat and Debian use 2.96 by default for building their current
releases on ia64; gcc 3.1 isn't in the debian archive for any
architectures yet, so I don't think that is an option.

> > I'm about to work up such a patch, for 1.4 initially.
> 
> If you do send such a patch, can you send with #ifdef's for
> broken gcc, and keep the old code for "non-broken-gcc" compilers.
> That way, when gcc2.x/3.0 falls out of common usage, it will
> be obvious to everyone how to cleanup (and *why* we shouldn't
> cleanup before then).

Can do, if you want.  Do you not agree that Davids proposal makes for better
code:

David Mosberger wrote:
> However, I also feel strongly the defining the efi_guid_t like this:
> 
> typedef struct {
>         uint32_t time_low;
>         uint16_t time_mid;
>         uint16_t time_hi_and_version;
>         uint8_t  clock_seq_hi_and_reserved;
>         uint8_t  clock_seq_low;
>         uint8_t  node[6];
> } __attribute__ ((packed)) efi_guid_t;
> 
> is fundamentally broken, because it introduces byte-order dependency.
> I'd recommend doing something along the following lines instead:
> 
> typedef unsigned char guid_t[16];
> #define EFI_GUID(a,b,c,b0,b1,b2,b3,b4,b5,b6,b7)                               
>  \
> { (a) & 0xff, ((a) >> 8) & 0xff, ((a) >> 16) & 0xff, ((a) >> 24) & 0xff, \
>   (b) & 0xff, ((b) >> 8) & 0xff,                                       \
>   (c) & 0xff, ((c) >> 8) & 0xff,                                       \
>   (b0), (b1), (b2), (b3), (b4), (b5), (b6), (b7) }
> 
> This is untested, but I think you'll get the idea.  This should be
> much better because it works independent of the host's byte-order and
> doesn't require using gcc-only extensions to C.  It will also work
> around the compiler bug until that gets fixed.

Cheers,
  Richard