Epicardium sensor stream use the FreRTOS Queue-API, which transfers
fixed size blobs of bytes. To work correctly, a client of this
API (like pycardium) must interpret the bytes received from the
queue the same way as the sender. Unfortunately, there is no way to
statically enforce this, so the existing code used a simple heuristic
to detect some misuses of the API: it checks that the size of the
buffer passed by the client to epic_stream_read is a whole multiple of
the sensor data size. But this is prone to errors: if the client
passes a buffer that can hold thirty data packets of size eight, but
accidentally specifies a queue with a packet size of six, the API may
read up to fourty data packets, and if the client doesn't check for
the possibillity that the API returns a number of read packets that is
larger than the maximum requested (which none of the (two) existing
clients did), it will happily read past the end of the buffer,
triggering undefined behavior.

The modified API does instead force the client to pass the size of the
data packets and the maximum number of packets to read, and so makes
sure that the API will never read more packets than requested. If the
client still happens to specify a wrong queue with the right packet
size it will of course still get garbage data.