Hi Renzo
I'm about to do tests using your excellent library.
When reading the documentation, I got a doubt when using
receiveInitialMessage.
In the library example, the Struct
MessageTemperature and
MessageHumidity are used.
For the receiver to identify the message (if about temperature or humidity) it is necessary to read the first part of the struct
char type[5];.
struct MessageTemperature {
char type[5];
char message[8];
byte temperature[4];
};
struct MessageHumidity {
char type[5];
char message[8];
byte humidity;
};
char type[5]; // first part of structure
ResponseContainer rs = e220ttl.receiveInitialMessage(sizeof(type));
However, if the developer creates a third struct to report the distance, but with 7 bytes in the identifier:
char type[7]:
That would cause a "memory leak" or a bug in "receiveInitialMessage", correct?
struct MessageDistance {
char type[7];
char message[8];
byte distance;
};
If the answer is yes, wouldn't it be interesting if
receiveInitialMessage had a behavior similar to
receiveMessageUntil, which would allow creating a delimiter for the field identifying the message?
ResponseContainer receiveInitialMessage(const uint8_t size);
ResponseContainer receiveMessageUntil(char delimiter = '\0');
Something like:
ResponseContainer rs = e220ttl.receiveInitialMessage(char delimiter = '\0');
struct MessageTemperature msg_t {"TEMP\0", ...};
struct MessageHumidity msg_h {"HUMI\0", ...};
struct MessageDistance msg_d {"distan\0", ...};
With this approach, there would be no danger of "memory leak" if the developer used a struct with an identification field larger than the receiveInitialMessage would be configured to read.
Am I talking nonsense or a mistake?
