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

[Johan Hedberg <johan.hedberg@gmail.com>]

Hi Luiz,

On Mon, Feb 21, 2011, Luiz Augusto von Dentz wrote:
> > 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