Dear Przemyslaw Marczak, In message <5321f4aa.4000...@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: w...@denx.de Heavier than air flying machines are impossible. -- Lord Kelvin, President, Royal Society, c. 1895 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot