[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