The current code assumes that the maximum in-memory size of a decoded GIF image is 4GiB, and makes limits above that impossible to express by using a u32 for storing the limit.
That assumption is incorrect - the maximum possible in-memory size is 16GiB (u16::MAXu16::MAX 4 bits per pixel). https://github.com/image-rs/image/issues/1052 also demonstrates images that occupy 7GiB in RAM per frame.
This PR changes the type for storing the maximum memory limit to a 64-bit value, and refactors the limit type into an enum while at it. It will still be represented as a plain u64 internally and will be trivially passable over FFI.
It is a semver-breaking change, but there is no way to fix this without an API break since the internal representation of the type is public.
The current code assumes that the maximum in-memory size of a decoded GIF image is 4GiB, and makes limits above that impossible to express by using a
u32for storing the limit.That assumption is incorrect - the maximum possible in-memory size is 16GiB (
u16::MAXu16::MAX4 bits per pixel). https://github.com/image-rs/image/issues/1052 also demonstrates images that occupy 7GiB in RAM per frame.This PR changes the type for storing the maximum memory limit to a 64-bit value, and refactors the limit type into an enum while at it. It will still be represented as a plain
u64internally and will be trivially passable over FFI.It is a semver-breaking change, but there is no way to fix this without an API break since the internal representation of the type is public.
This is a part of the work on fixing https://github.com/image-rs/image/issues/1052