Closed fintelia closed 6 months ago
Wouldn't it make sense to change the types to NonZeroU32
then?
Switching to NonZeroU32
would be an API breaking change. There's also a lot of places throughout the image-rs collection of crates that work with image widths and heights represented as normal integers rather than non-zero integers, so that would have to be a broader discussion than just this one place
The image in the unit test declares the size of 0 x 3
, so the decoder is entirely correct in rejecting it.
I've changed the width from 0 to 1 using a hex editor and the file is still broken, just in a different way.
Looking at the PR that introduced it, it seems it was original file was generated by a fuzzer. I don't think it would be feasible to craft a file that triggers the same now-fixed issue, at least not without using a fuzzer and tying it to the implementation details of the library again.
I propose to simply remove the failing test, since there is no reasonable way for us to keep it and fix the 0-size panic.
The PNG spec states:
Fixes #444 Fixes #438