*data_length = packet->p->tot_len;...*data_length = (uint16_t)(*data_length - offset);E.g., if I have a netbuf of 2 pbufs of 5 bytes, and read at offset 0:
data_length = 10available_length = 10data = ... pbuf (5 bytes)So I will read past the end of data if I try to read more than 5 bytes.I think the initial value should be the length of the current pbuf:
*data_length = packet->p->len;...*data_length = (uint16_t)(*data_length - offset);So same read at 0 would be:
data_length = 5available_length = 10data = ... pbuf (5 bytes)
*data_length = packet->p->tot_len;should be
*data_length = packet->ptr->len;
WICED currently does not support chained packet buffers and so much of the code assumes that tot_len and len are equal. In fact there are places that assert that p->tot_len == p->len.That means we can change from using tot_len to len without affecting existing functionality but allows WICED to be better prepared for supporting chained packet buffers in the future.An internal issue has been raised to review our use of tot_len and len.Thank you for your feedbackYou are referring to the internals of the LWIP netbuf, but does this mean that at the WICED API level:1. calling wiced_tcp_receive() today always returns wiced packet with a single contiguous buffer?2. passing this packet to wiced_packet_get_data will always return a pointer to this single buffer, and both the data_length and available_data_length will be the same, equal to the received amount of data in this packet?