Re: gcc bug causes parted to write bad GPT entries

[Richard Hirst]

On Sat, Mar 16, 2002 at 10:53:50AM +1100, Andrew Clausen wrote:
> The problem with this is you can't "unparse" it.

Agreed.  This is making my brain hurt; the guid is on disk in
little-endian order.  disk_gpt.c swaps to local cpu order when it reads
them, and back to LE when it writes them.  That's good, but the libuuid
code, which can be used to unparse them, looks like it interprets the 16
byte block it is passed as a uuid in big endian order (regardless of
local cpu byte order).  libuuid is used to generate unique UUIDs for the
partitions too.  That should mean the unique partition IDs written by
parted are wrong byte order on LE machines.  That does indeed seem to be
the case; if I run uuidgen a few times, I get strings like

a9e984b7-3c7b-4f1c-8764-f941fdaf6775

where this    ^    digit is always a 4

libuuid forces that to 4 as part of its generating process.  So, on disk
that should be in LE format, and so the 8th byte (offset 7) of the
unique guid should be 0x4?.  But it isn't, on my disks it is the 7th
byte that always has a value 0x4?.

Am I confused, or is the code broken in the way it interacts with
libuuid?

I saw there were some changes in 1.6, maybe this has been addressed
there?

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

Don't see how it gives you lots of magic numbers.

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

OK.

Another possible option is to simply remove the ((packed)) attribute
from the struct definition:

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;

I don't see why that struct needs the attribute anyway; the members are
sorted largest first so I wouldn't expect any padding.  If I remove it,
then gcc sticks a .align 4 before it, and everything appears to be
happy.  I'll look more closely at that approach over the weekend.

Thanks for the comments,

Richard