LibCompress+LibGfx+LibPDF: Factorize the PackBits decoder
@warpdesign, I tested this PR on the B-WING file you gave in https://github.com/SerenityOS/serenity/pull/22287, but do you know if the test you added also triggers the bug on the while loop?
@warpdesign, I tested this PR on the B-WING file you gave in
https://github.com/SerenityOS/serenity/pull/22287, but do you know if the test you added also triggers the bug on the while loop?
Just tested: the test file I added doesn't trigger the bug.
That would be nice to either generate one or find a royalty free one to prevent future regressions.
That would be nice to either generate one or find a royalty free one to prevent future regressions.
Yeah, I tried generating my own files using ppmtoilbm but wasn't able to generate one that makes the previous loop break.
I thought about contacting the author of the b-wing file but the README file only contains a phone number sigh.. welcome to 1994 ;)
I'll try to generate a buggy one with some old Amiga tools later.
Would be nice to have a few tests.
Sure, I will do that tonight. Yeah, I'm really not sure if this is worth a fuzzer.
The end of stream symbol is mentioned in the PDF spec, but I suspect that it was at some point in the original PackBits description, as the symbol is reserved anyway. Also for the signed vs unsigned difference, values are compatible so that's not an issue. However, it's easier to describe the range with unsigned values (only one test (< 127) is needed while two are present in the corresponding ILBM version). I will add some comments to clarify that.
From chat: pdf-raku/stillhq.com-pdfdb@main/000582.pdf is the one PDF file I could find that uses /RunLengthEncoding
This PR fixes a crash on your example lol There is more data after the EOS symbol, and it used to crash on this line, now it errors on Image Masks
(Red CI is unrelated, must've just missed e89163911c118)