Hi, On Mon, Feb 21, 2011 at 6:54 PM, Johan Hedberg <johan.hedberg@xxxxxxxxx> wrote: > 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. Sound good to me. -- Luiz Augusto von Dentz Computer Engineer -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
