Stefan Seyfried

the EOL marker is actually 6 Bytes IIUC: it's "write_rle_argb(rle, 0, 0);" which will write 6 0x0 bytes. And my "worst case is 4=>6 bytes" statement was actually true: consider a line of individually colored (no two successive pixels same color) but all transparent (alpha==0). Then you'll get 6 bytes for every pixel. Plus 6 bytes EOL. So a "+6" (or 'w+1') in these calculations might be better.

Sorry, only got notified today about updates in this issue. I did have debug prints in and it reallocated not very often, in fact I think it reallocated less often than the original code. Most of the time, there are two allocations: one at start, one at around y=2 to y=4 which then is enough. Sometimes a third one shortly before the end, if the estimation was not good enough. From my logs at the time: rle_size: 13356 w: 1113 h: 606 used: 0 y: 0 rle_size: 2030112 w: 1113 h: 606 used: 6857 y: 4 rle_size:...

I forgot: this happens with git master, commit 977ff048201349

second patch fixes the buffer size calculation and tries to be clever wrt. buffer size to not realloc() too often.

buffer overrun in rle_compress_argbrle