[U-Boot] [PATCH v4 2/6] lib: uuid: code refactor for proper maintain between uuid bin and string

[Stephen Warren <swarren@wwwdotorg.org>]

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.