[core/cyclicbuffer] : cherry pick from '6ee3271693a84897b0208f2af954d…71054b1eed4'.

[msieben]

Include the last element in writing. It is unintuitive that the anmount of data is always 1 less than the (maximum) size.

[VeithMetro]

I do agree that in theory Write() and Read() should be symmetrical, and it is in fact strange that the ASSERT in Read() is less equal meanwhile here in Write it is just less. So, in theory, it should probably be less equal.

But could you test if perhaps some other changes are necessary because of changing this ASSERT?

You could use the tests for each overflow corner case I made in this commit (ff3c391), and modify them so that the buffers one byte bigger.

[msieben]

I do agree that in theory Write() and Read() should be symmetrical, and it is in fact strange that the ASSERT in Read() is less equal meanwhile here in Write it is just less. So, in theory, it should probably be less equal.

But could you test if perhaps some other changes are necessary because of changing this ASSERT?

You could use the tests for each overflow corner case I made in this commit (ff3c391), and modify them so that the buffers one byte bigger.

Just ran the these modified tests. One fails.

OffsetCutPushDataShouldFlushOldDataIfDoesNotFitOffsetCut with uint8_t fullBufferSimulation[DATA_SIZE - sizeof(uint16_t)] fails with ERROR_WRITE_ERROR.

[VeithMetro]

Just ran the these modified tests. One fails.
OffsetCutPushDataShouldFlushOldDataIfDoesNotFitOffsetCut with uint8_t fullBufferSimulation[DATA_SIZE - sizeof(uint16_t)] fails with ERROR_WRITE_ERROR.

@sebaszm should we leave it for now as it is, and have a look into it in the future? Since changing the ASSERT clearly means we have to make some more changes to make both Read() and Write() symmetrical

[msieben]

Closing PR as it has been decided to accept the mismatch.