Re: [RFC v2 00/14] Store UUID-128 on host order

Hi Luiz,

On Mon, Feb 21, 2011, Luiz Augusto von Dentz wrote:

quoted

Just throwing my own bits on this: I think making the internal
representation for uuid_t consistent is important to avoid bugs when
handling the different UUID types.

currently uuid_t stores 16/32-bit uuids and 128-bit uuid differently.

The problem is not the internal representation, but things like this:

-       sdp_uuid128_create(&svclass_uuid, SYNCMLC_UUID);
+       ntoh128(SYNCMLC_UUID, &h128);
+       sdp_uuid128_create(&svclass_uuid, &h128);

This means the API has changed, it now takes host order where it used
to be network order. We could have a new function e.g.
sdp_uuid128h_create to handle such cases and not break existing
applications using this API.

In this particular case the prefix sdp_ already implies that this is for
SDP and shouldn't be used in other code. I think what makes sense (and
Marcel supported it in IRC) is to a new bt_uuid_t struct and bt_uuid_*
helper functions which internally store everything in host byte order.
Then in the first phase we can make the ATT code use the new API and
later in a second phase start converting existing SDP code to use it.

Johan