Re: gcc bug causes parted to write bad GPT entries

[Andrew Clausen]

On Fri, Mar 15, 2002 at 10:15:29PM +0000, Richard Hirst wrote:
> > 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.

yet ;)

> > > 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.

So you need endianness macros, which are yucky, agreed...

> > 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) }

The problem with this is you can't "unparse" it.

> > 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.

It also makes it impossible to manipulate the data inside, and
gives us lots of magic numbers.

Equally importantly, the rest of libparted follows the opposite
convention: use of endian macros.

Andrew