Activity for Stefan Seyfried
-
Stefan Seyfried posted a comment on ticket #90
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
1