You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Everywhere in the library a std::string is used to store data as some kind of buffer, e.g service data, remote characteristic values, manufacturer data, etc. I believe that this data is binary, and so may include bytes of 0x00. But if a std::string is created with a zero somewhere in the middle, it is truncated at this zero as demonstrated by below sketch:
#include <string>
void setup() {
Serial.begin(115200);
Serial.println("\n\nStarted");
std::string demonstrate("\x35\x34\x33\x32\x31\x00\x31\x32\x33\x34\x35");
Serial.printf("The length of the string is %u, it's size is %u and it's value is '%s'\n", demonstrate.length(), demonstrate.size(), demonstrate.c_str());
}
void loop() {
// put your main code here, to run repeatedly:
}
The output of this small program is:
Started
The length of the string is 5, it's size is 5 and it's value is '54321'
It is fully logical that length() == 5. If size() would be 11, then the underlying data could be fully retrieved. But since this is also 5, the zero byte and the 5 bytes following the zero will be truncated, if such data was sent by a device.
I think there are two options:
Use a uint8_t buffer[] everywhere. Also return a (const) uint8_t * pointer for e.g. the readValue() functions. Pro: easy, con: memory mgt is needed
Use a vector<uint8_t> everywhere. Also return a (const) vector<uint8_t> & for e.g. readValue(). Pro: no memory mgt is needed, the getSize() functions can be removed because the vector::size() can be used. Con: a STL container is used instead of a plain array.
Both options will break @h2zero's strategy to remain compatible with the original BLE library. But if I am right I think this is needed!
The text was updated successfully, but these errors were encountered:
While std:string isn't ideal for this, it is easy to use. If you wanted to send that data that way you could just specify the length, the only thing that wouldn't work is the c_str(), but if you're working with binary data you probably won't be printing it as a string.
Everywhere in the library a std::string is used to store data as some kind of buffer, e.g service data, remote characteristic values, manufacturer data, etc. I believe that this data is binary, and so may include bytes of 0x00. But if a std::string is created with a zero somewhere in the middle, it is truncated at this zero as demonstrated by below sketch:
The output of this small program is:
It is fully logical that
length() == 5
. Ifsize()
would be 11, then the underlying data could be fully retrieved. But since this is also 5, the zero byte and the 5 bytes following the zero will be truncated, if such data was sent by a device.I think there are two options:
uint8_t buffer[]
everywhere. Also return a (const)uint8_t *
pointer for e.g. thereadValue()
functions. Pro: easy, con: memory mgt is neededvector<uint8_t>
everywhere. Also return a (const)vector<uint8_t> &
for e.g.readValue()
. Pro: no memory mgt is needed, thegetSize()
functions can be removed because thevector::size()
can be used. Con: a STL container is used instead of a plain array.Both options will break @h2zero's strategy to remain compatible with the original BLE library. But if I am right I think this is needed!
The text was updated successfully, but these errors were encountered: