Bug on 32-bit architectures

[EML100]

On GCC 8, Raspberry Pi 4 (ARM Cortex-A72) unsigned long is 32-bit. There are 6 calls to strtoul in BlueToothUUID.cpp, which are assumed to return 64 bits; the return values should be casted to uint64_t. gcc produces warnings for 3 of these calls (where the return value is incorrectly left-shifted by 32 or more bits).

On another note...

I think this is a great project, as I really don't want to start messing around with the undocumented BlueZ DBus API. OTOH, I don't think I'll get much further using it for the RPi (the C++ hellotinyb crashes, for example). I know this is the wrong place to ask, but can anyone suggest a replacement? There are a couple of other attempts at C++ APIs but I think they may be old and unmaintained. Or should I bite the bullet and try to figure out how to use BlueZ directly?

[EML100]

Actually, this is looking better than I thought:

• I had previously only fixed the 3 calls to strtoul that gcc flagged as warnings. When I fix all 6 of them, hellotinyb no longer crashes

• I had previously run hellotinyb using lower-case hex characters in the device MAC address. This doesn't work, and hellotinyb reports that it can't find the device, because it's doing an unintelligent string compare against an upper-case version. This should really be reported as a bug as well, if anyone's still interested...