Handling of 32 and 128 bit uuids for BLE

I've some problems in understanding handling of uuids in Espruino.
AFAIK, ble_uuid_t is used to work with uuids
ble_uuid_t.uuid is a 16 bit value only, and type can be unknown, 16 bit and 128 bit
What happens with the full uuid for 128 bit ?

For ESP32 we have a struct , which supports 16/32/128 bit uuids
In actual port for ESP32 only 16 bit is supported. This was fine for first steps into the new world, but should not be the end of the story.
Any recommendation, how we get this together ?

typedef struct {
[#define](http://forum.espruino.com/sear­ch/?q=%23define) ESP_UUID_LEN_16     2
[#define](http://forum.espruino.com/sear­ch/?q=%23define) ESP_UUID_LEN_32     4
[#define](http://forum.espruino.com/sear­ch/?q=%23define) ESP_UUID_LEN_128    16
    uint16_t len;							/*!< UUID length, 16bit, 32bit or 128bit */
    union {
        uint16_t    uuid16;
        uint32_t    uuid32;
        uint8_t     uuid128[ESP_UUID_LEN_128];
    } uuid;									/*!< UUID */
} __attribute__((packed)) esp_bt_uuid_t;

Yes, it's a bit weird. In the 128 bit case, the majority of the UUID is stored elsewhere with sd_ble_uuid_vs_add: https://github.com/espruino/Espruino/blo­b/master/libs/bluetooth/bluetooth_utils.­c#L160

Then the ->type field stores an index into this UUID, while ->uuid contains bytes 12 and 13 of the 128 bit UUID.

It seems to be side-effect of the softdevice... So either you could implement something similar in ESP32-land, or I guess we could have something more general than ble_uuid_t - but that would have some pretty huge knock-on effects I believe :(

hmmm, I could implement something similiar. But IMHO, the word weird woule be a good description for that.
On the other hand, a totally new ble_uuid_t, I agree, could have a lot of side effects.

Could it be an option for a first step to add a uuid128 field to ble_uuid_t(bluetooth.h) for non NRF52 boards ?
Uuid and type would stay the way they are used today. For NRF52 everything would stay the way it is now.
Some more ifdef lines (in bleUUIDEqual,bleVarToUUID) would use this field for 128bit uuids. For 16/32 bit uuids, this could be filled with standard mask (00000000-0000-1000-8000-00805F9B34FB or 16/32 uuids into)

Could it be an option for a first step to add a uuid128 field to ble_uuid_t(bluetooth.h) for non NRF52 boards ?

Yes, that sounds like a much better idea! I guess you could just make uuid a 16 byte array, and use type to decide if it was 128 bit or if just the first 2 bytes of it were used?

I'm not sure if that'd cause any problems down the line, but probably not that many...