RE: gcc bug causes parted to write bad GPT entries

[Matt_Domsch]

> On Mon, Mar 18, 2002 at 11:48:18AM +0000, Richard Hirst wrote:
> > The GUIDs are on disk in LE byte order, libuuid works in BE 
> byte order.
> > 
> > Options:
> > 
> > 1. Leave code as is, but add cpu_to_be()/be_to_cpu() 
> swapping round calls
> > to libuuid.  Could just have be_to_cpu() after 
> uuid_generate(), and have
> > local parse_le() unparse_le() functions.
> 
> Checking the archives, I see Matt Domsch sent a variant of this:
> 
> http://domsch.com/linux/patches/parted/parted-1.4.23-gpt-swab.patch
> 
> back in January, but it wasn't included in 1.4.24.  It actaully looks
> broken to me, because it just byteswaps regardless of local CPU byte
> order.  Anyway, perhaps that indicates a preference for my option 1.

I don't think local CPU byte order matters.
The RFC (hence libuuid) generates it in big-endian byte order always.
EFI uses it in little-endian byte order always.
So, the simple swab32 and swab16 calls make one into the other, but you've
got to keep track of which way you're dealing with it to know when to call
the swab.
 
> So now we have a chioce of
> 
> a) a fixed version of Matt's patch plus my gcc bug workaround
> b) my option 2 (manage as big-endian arrays of bytes throughout)

I've got no care one way or the other, as long as the EFI_GUID() macro
follows suit also.  There, the values are written in big-endian notation (as
all integers are when written out longhand), and those have some special
globally-assigned meanings.

If you'd like to make either patch, I'd be happy for it. :-)

Thanks,
Matt

--
Matt Domsch
Sr. Software Engineer
Dell Linux Solutions www.dell.com/linux
Linux on Dell mailing lists @ http://lists.us.dell.com
#1 US Linux Server provider for 2001!