On 03/26/2014 06:00 AM, Przemyslaw Marczak wrote: > Hello Stephen, > Thanks for review again:) > > On 03/25/2014 08:12 PM, Stephen Warren wrote: >> On 03/19/2014 11:58 AM, Przemyslaw Marczak wrote: >>> Changes in lib/uuid.c to: >>> - uuid_str_to_bin() >>> - uuid_bin_to_str() >>> >>> New parameter is added to specify input/output string format in >>> listed functions >>> This change allows easy recognize which UUID type is or should be >>> stored in given >>> string array. Binary data of UUID and GUID is always stored in big >>> endian, only >>> string representations are different as follows. >>> >>> String byte: 0 36 >>> String char: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx >>> string UUID: be be be be be >>> string GUID: le le le be be >>> >>> This patch also updates functions calls and declarations in a whole >>> code.
>>> diff --git a/lib/uuid.c b/lib/uuid.c >> >> >>> +void uuid_bin_to_str(unsigned char *uuid_bin, char *uuid_str, >>> + uuid_str_t str_format) >>> { >>> - static const u8 le[16] = {3, 2, 1, 0, 5, 4, 7, 6, 8, 9, 10, 11, >>> - 12, 13, 14, 15}; >>> + const u8 uuid_char_order[UUID_BIN_LEN] = {0, 1, 2, 3, 4, 5, 6, >>> 7, 8, >>> + 9, 10, 11, 12, 13, 14, 15}; >>> + const u8 guid_char_order[UUID_BIN_LEN] = {3, 2, 1, 0, 5, 4, 7, >>> 6, 8, >>> + 9, 10, 11, 12, 13, 14, 15}; >> >> These are really more binary data order than char order, since each one >> of the bytes pointed at by entries in these arrays ends up being 2 >> characters. s/char/bin/ in the variable names perhaps? > > Yes, you are right. But according to the specification UUID and UUID bin > format are always in big-endian - only bytes in some STRING blocks have > different order. This works in two ways but to be consistent with > specification I called this as "uuid_char_order". And this is directly > used by sprintf: "sprintf(uuid_str, "%02x", uuid_bin[char_order[i]]);". That doesn't make much sense. If I have 2 bytes stored in memory as: 0xaa 0x55 ... and sometimes the string representation of them is aa55 and sometimes 55aa, then *by definition*, that's interpreting the binary data as BE vs LE. The binary data is not always BE. The only exception would be if for bytes in memory 0xaa 0x55 the 16-bit integer/numerical (in-register) value was always 0xaa55 (BE), yet the string representation of that integer was sometimes aa55 and sometimes 55aa. However, that's not how integer->string conversion works. Different string representations of the binary data would only be possible if the binary data isn't an integer but rather a string of bytes, yet endianness has no meaning for data that is natively a string of bytes, only for larger values that have been serialized into a string of bytes. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot