[U-Boot] [PATCH V2 2/3] lib: uuid: add functions to generate UUID version 4

Wolfgang Denk wd at denx.de
Thu Mar 13 19:41:25 CET 2014


Dear Przemyslaw Marczak,

In message <5321F4AA.4000402 at samsung.com> you wrote:
> 
> > Is that structure definition endianness-safe?
> 
> UUID format is big-endian.

OK.  Then you must make sure to store the data such that they result
in a big endian data format.

> Actually for version 4 it doesn't matter because of it is random, and 
> RFC says that version and variant are the most significant bits of 
> proper structure field. In this code version and variant mask are stored 
> at most significant bits - so this is big endian.
> Actually we uses it as a string and as you can check in generated uuids 
> its proper. As wiki says:
> "Version 4 UUIDs have the form xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx 
> where x is any hexadecimal digit and y is one of 8, 9, A, or B (e.g., 
> f47ac10b-58cc-4372-a567-0e02b2c3d479)."
> 
> Even if this code runs on big-endian machine, version and variant are 
> still set properly (most significant bits).

I don't see how come to this conclusion.  As far as I can see, you
initialize a binary data structure (where data storage _does_ depend
on the endianess), and then simply use this memory area - there is no
endianess handling anywhere.

Please also note that your code needs fixing due to alignment issues.
You cannot just cast a struct pointer which requires 32 bit alignment
to an arbitrary (i. e. unaligned) char pointer (comment to patch sent).

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Heavier than air flying machines are impossible.
                    -- Lord Kelvin, President, Royal Society, c. 1895


More information about the U-Boot mailing list