Dear Przemyslaw Marczak,
In message 5321F4AA.4000402@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