Questions about possible memory leak when using “receiveInitialMessage”

[george_santiago]

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?

[Renzo Mischianti]

Hi George,
I think the simple solution is to send a fixed TYPE and decode it to the receiver.
The message isn’t applicable on binary stream.
Bye Renzo

[Author]

Posts