Add Limits for pre-allocation resource control

[lilith]

Summary

Adds caller-configurable resource limits without touching any decoder code. Every field is optional — unset limits add zero overhead.

use rawloader::Limits;let limits = Limits{max_pixels:Some(50_000_000),
..Limits::default()};let image = rawloader::decode_file_with_limits("photo.cr2",&limits)?;

How it works

When limits has any dimension limit set, decode_with_limits reuses the existing dummy=true path: it parses all the metadata, allocates only a 1-element placeholder vec, and returns a RawImage with width/height populated. Same code that fuzzing uses via decode_dummy.

The flow:

1. Probe:decode_unsafe(buffer, true) — full metadata parse, no pixel allocation
2. Validate: check dimensions against limits
3. Real decode:decode_unsafe(buffer, false) only if dimensions fit

Rejected files never allocate the pixel buffer. Metadata parsing happens twice but it's cheap (microseconds) compared to the actual decode.

When all dimension limits are None, the probe is skipped entirely and decode_with_limits has the same cost as decode(). Only max_input_bytes (a cheap size check) is applied in that case.

What this doesn't change

• Existing decode, decode_file, decode_dummy, decode_unwrapped are untouched
• No decoder code, no macros, no decode_threaded, no packed functions
• The internal alloc_image_plain! 500M/50k panic still acts as a backstop for code paths that don't go through decode_with_limits

Public API additions

pubstructLimits{pubmax_pixels:Option<u64>,pubmax_side:Option<u64>,pubmax_input_bytes:Option<u64>,}pubfndecode_with_limits(reader:&mutdynRead,limits:&Limits) -> Result<RawImage,RawLoaderError>;pubfndecode_file_with_limits<P:AsRef<Path>>(path:P,limits:&Limits) -> Result<RawImage,RawLoaderError>;

Diff

140 insertions / 1 deletion across 2 files (src/decoders/mod.rs, src/lib.rs).

The 1 deletion is an unrelated single-line clippy fix (decoders::RawLoader::new() → RawLoader::new()) that was preventing clean compile on master.

[lilith]

Summary

Adds caller-configurable resource limits without touching any decoder code. Every field is optional — unset limits add zero overhead.

use rawloader::Limits;let limits = Limits{max_pixels:Some(50_000_000),
..Limits::default()};let image = rawloader::decode_file_with_limits("photo.cr2",&limits)?;

How it works

When limits has any dimension limit set, decode_with_limits reuses the existing dummy=true path: it parses all the metadata, allocates only a 1-element placeholder vec, and returns a RawImage with width/height populated. Same code that fuzzing uses via decode_dummy.

The flow:

1. Probe:decode_unsafe(buffer, true) — full metadata parse, no pixel allocation
2. Validate: check dimensions against limits
3. Real decode:decode_unsafe(buffer, false) only if dimensions fit

Rejected files never allocate the pixel buffer. Metadata parsing happens twice but it's cheap (microseconds) compared to the actual decode.

When all dimension limits are None, the probe is skipped entirely and decode_with_limits has the same cost as decode(). Only max_input_bytes (a cheap size check) is applied in that case.

What this doesn't change

• Existing decode, decode_file, decode_dummy, decode_unwrapped are untouched
• No decoder code, no macros, no decode_threaded, no packed functions
• The internal alloc_image_plain! 500M/50k panic still acts as a backstop for code paths that don't go through decode_with_limits

Public API additions

pubstructLimits{pubmax_pixels:Option<u64>,pubmax_side:Option<u64>,pubmax_input_bytes:Option<u64>,}pubfndecode_with_limits(reader:&mutdynRead,limits:&Limits) -> Result<RawImage,RawLoaderError>;pubfndecode_file_with_limits<P:AsRef<Path>>(path:P,limits:&Limits) -> Result<RawImage,RawLoaderError>;

Diff

140 insertions / 1 deletion across 2 files (src/decoders/mod.rs, src/lib.rs).

The 1 deletion is an unrelated single-line clippy fix (decoders::RawLoader::new() → RawLoader::new()) that was preventing clean compile on master.

[lilith]

Summary

Adds caller-configurable resource limits without touching any decoder code. Every field is optional — unset limits add zero overhead.

use rawloader::Limits;let limits = Limits{max_pixels:Some(50_000_000),
..Limits::default()};let image = rawloader::decode_file_with_limits("photo.cr2",&limits)?;

How it works

When limits has any dimension limit set, decode_with_limits reuses the existing dummy=true path: it parses all the metadata, allocates only a 1-element placeholder vec, and returns a RawImage with width/height populated. Same code that fuzzing uses via decode_dummy.

The flow:

1. Probe:decode_unsafe(buffer, true) — full metadata parse, no pixel allocation
2. Validate: check dimensions against limits
3. Real decode:decode_unsafe(buffer, false) only if dimensions fit

Rejected files never allocate the pixel buffer. Metadata parsing happens twice but it's cheap (microseconds) compared to the actual decode.

When all dimension limits are None, the probe is skipped entirely and decode_with_limits has the same cost as decode(). Only max_input_bytes (a cheap size check) is applied in that case.

What this doesn't change

• Existing decode, decode_file, decode_dummy, decode_unwrapped are untouched
• No decoder code, no macros, no decode_threaded, no packed functions
• The internal alloc_image_plain! 500M/50k panic still acts as a backstop for code paths that don't go through decode_with_limits

Public API additions

pubstructLimits{pubmax_pixels:Option<u64>,pubmax_side:Option<u64>,pubmax_input_bytes:Option<u64>,}pubfndecode_with_limits(reader:&mutdynRead,limits:&Limits) -> Result<RawImage,RawLoaderError>;pubfndecode_file_with_limits<P:AsRef<Path>>(path:P,limits:&Limits) -> Result<RawImage,RawLoaderError>;

Diff

140 insertions / 1 deletion across 2 files (src/decoders/mod.rs, src/lib.rs).

The 1 deletion is an unrelated single-line clippy fix (decoders::RawLoader::new() → RawLoader::new()) that was preventing clean compile on master.

[lilith]

Summary

Adds caller-configurable resource limits without touching any decoder code. Every field is optional — unset limits add zero overhead.

use rawloader::Limits;let limits = Limits{max_pixels:Some(50_000_000),
..Limits::default()};let image = rawloader::decode_file_with_limits("photo.cr2",&limits)?;

How it works

When limits has any dimension limit set, decode_with_limits reuses the existing dummy=true path: it parses all the metadata, allocates only a 1-element placeholder vec, and returns a RawImage with width/height populated. Same code that fuzzing uses via decode_dummy.

The flow:

1. Probe:decode_unsafe(buffer, true) — full metadata parse, no pixel allocation
2. Validate: check dimensions against limits
3. Real decode:decode_unsafe(buffer, false) only if dimensions fit

Rejected files never allocate the pixel buffer. Metadata parsing happens twice but it's cheap (microseconds) compared to the actual decode.

When all dimension limits are None, the probe is skipped entirely and decode_with_limits has the same cost as decode(). Only max_input_bytes (a cheap size check) is applied in that case.

What this doesn't change

• Existing decode, decode_file, decode_dummy, decode_unwrapped are untouched
• No decoder code, no macros, no decode_threaded, no packed functions
• The internal alloc_image_plain! 500M/50k panic still acts as a backstop for code paths that don't go through decode_with_limits

Public API additions

pubstructLimits{pubmax_pixels:Option<u64>,pubmax_side:Option<u64>,pubmax_input_bytes:Option<u64>,}pubfndecode_with_limits(reader:&mutdynRead,limits:&Limits) -> Result<RawImage,RawLoaderError>;pubfndecode_file_with_limits<P:AsRef<Path>>(path:P,limits:&Limits) -> Result<RawImage,RawLoaderError>;

Diff

140 insertions / 1 deletion across 2 files (src/decoders/mod.rs, src/lib.rs).

The 1 deletion is an unrelated single-line clippy fix (decoders::RawLoader::new() → RawLoader::new()) that was preventing clean compile on master.

[lilith]

Summary

Adds caller-configurable resource limits without touching any decoder code. Every field is optional — unset limits add zero overhead.

use rawloader::Limits;let limits = Limits{max_pixels:Some(50_000_000),
..Limits::default()};let image = rawloader::decode_file_with_limits("photo.cr2",&limits)?;

How it works

When limits has any dimension limit set, decode_with_limits reuses the existing dummy=true path: it parses all the metadata, allocates only a 1-element placeholder vec, and returns a RawImage with width/height populated. Same code that fuzzing uses via decode_dummy.

The flow:

1. Probe:decode_unsafe(buffer, true) — full metadata parse, no pixel allocation
2. Validate: check dimensions against limits
3. Real decode:decode_unsafe(buffer, false) only if dimensions fit

Rejected files never allocate the pixel buffer. Metadata parsing happens twice but it's cheap (microseconds) compared to the actual decode.

When all dimension limits are None, the probe is skipped entirely and decode_with_limits has the same cost as decode(). Only max_input_bytes (a cheap size check) is applied in that case.

What this doesn't change

• Existing decode, decode_file, decode_dummy, decode_unwrapped are untouched
• No decoder code, no macros, no decode_threaded, no packed functions
• The internal alloc_image_plain! 500M/50k panic still acts as a backstop for code paths that don't go through decode_with_limits

Public API additions

pubstructLimits{pubmax_pixels:Option<u64>,pubmax_side:Option<u64>,pubmax_input_bytes:Option<u64>,}pubfndecode_with_limits(reader:&mutdynRead,limits:&Limits) -> Result<RawImage,RawLoaderError>;pubfndecode_file_with_limits<P:AsRef<Path>>(path:P,limits:&Limits) -> Result<RawImage,RawLoaderError>;

Diff

140 insertions / 1 deletion across 2 files (src/decoders/mod.rs, src/lib.rs).

The 1 deletion is an unrelated single-line clippy fix (decoders::RawLoader::new() → RawLoader::new()) that was preventing clean compile on master.

[lilith]

Summary

Adds caller-configurable resource limits without touching any decoder code. Every field is optional — unset limits add zero overhead.

use rawloader::Limits;let limits = Limits{max_pixels:Some(50_000_000),
..Limits::default()};let image = rawloader::decode_file_with_limits("photo.cr2",&limits)?;

How it works

When limits has any dimension limit set, decode_with_limits reuses the existing dummy=true path: it parses all the metadata, allocates only a 1-element placeholder vec, and returns a RawImage with width/height populated. Same code that fuzzing uses via decode_dummy.

The flow:

1. Probe:decode_unsafe(buffer, true) — full metadata parse, no pixel allocation
2. Validate: check dimensions against limits
3. Real decode:decode_unsafe(buffer, false) only if dimensions fit

Rejected files never allocate the pixel buffer. Metadata parsing happens twice but it's cheap (microseconds) compared to the actual decode.

When all dimension limits are None, the probe is skipped entirely and decode_with_limits has the same cost as decode(). Only max_input_bytes (a cheap size check) is applied in that case.

What this doesn't change

• Existing decode, decode_file, decode_dummy, decode_unwrapped are untouched
• No decoder code, no macros, no decode_threaded, no packed functions
• The internal alloc_image_plain! 500M/50k panic still acts as a backstop for code paths that don't go through decode_with_limits

Public API additions

pubstructLimits{pubmax_pixels:Option<u64>,pubmax_side:Option<u64>,pubmax_input_bytes:Option<u64>,}pubfndecode_with_limits(reader:&mutdynRead,limits:&Limits) -> Result<RawImage,RawLoaderError>;pubfndecode_file_with_limits<P:AsRef<Path>>(path:P,limits:&Limits) -> Result<RawImage,RawLoaderError>;

Diff

140 insertions / 1 deletion across 2 files (src/decoders/mod.rs, src/lib.rs).

The 1 deletion is an unrelated single-line clippy fix (decoders::RawLoader::new() → RawLoader::new()) that was preventing clean compile on master.

[lilith]

Summary

Adds caller-configurable resource limits without touching any decoder code. Every field is optional — unset limits add zero overhead.

use rawloader::Limits;let limits = Limits{max_pixels:Some(50_000_000),
..Limits::default()};let image = rawloader::decode_file_with_limits("photo.cr2",&limits)?;

How it works

When limits has any dimension limit set, decode_with_limits reuses the existing dummy=true path: it parses all the metadata, allocates only a 1-element placeholder vec, and returns a RawImage with width/height populated. Same code that fuzzing uses via decode_dummy.

The flow:

1. Probe:decode_unsafe(buffer, true) — full metadata parse, no pixel allocation
2. Validate: check dimensions against limits
3. Real decode:decode_unsafe(buffer, false) only if dimensions fit

Rejected files never allocate the pixel buffer. Metadata parsing happens twice but it's cheap (microseconds) compared to the actual decode.

When all dimension limits are None, the probe is skipped entirely and decode_with_limits has the same cost as decode(). Only max_input_bytes (a cheap size check) is applied in that case.

What this doesn't change

• Existing decode, decode_file, decode_dummy, decode_unwrapped are untouched
• No decoder code, no macros, no decode_threaded, no packed functions
• The internal alloc_image_plain! 500M/50k panic still acts as a backstop for code paths that don't go through decode_with_limits

Public API additions

pubstructLimits{pubmax_pixels:Option<u64>,pubmax_side:Option<u64>,pubmax_input_bytes:Option<u64>,}pubfndecode_with_limits(reader:&mutdynRead,limits:&Limits) -> Result<RawImage,RawLoaderError>;pubfndecode_file_with_limits<P:AsRef<Path>>(path:P,limits:&Limits) -> Result<RawImage,RawLoaderError>;

Diff

140 insertions / 1 deletion across 2 files (src/decoders/mod.rs, src/lib.rs).

The 1 deletion is an unrelated single-line clippy fix (decoders::RawLoader::new() → RawLoader::new()) that was preventing clean compile on master.

[lilith]

Summary

Adds caller-configurable resource limits without touching any decoder code. Every field is optional — unset limits add zero overhead.

use rawloader::Limits;let limits = Limits{max_pixels:Some(50_000_000),
..Limits::default()};let image = rawloader::decode_file_with_limits("photo.cr2",&limits)?;

How it works

When limits has any dimension limit set, decode_with_limits reuses the existing dummy=true path: it parses all the metadata, allocates only a 1-element placeholder vec, and returns a RawImage with width/height populated. Same code that fuzzing uses via decode_dummy.

The flow:

1. Probe:decode_unsafe(buffer, true) — full metadata parse, no pixel allocation
2. Validate: check dimensions against limits
3. Real decode:decode_unsafe(buffer, false) only if dimensions fit

Rejected files never allocate the pixel buffer. Metadata parsing happens twice but it's cheap (microseconds) compared to the actual decode.

When all dimension limits are None, the probe is skipped entirely and decode_with_limits has the same cost as decode(). Only max_input_bytes (a cheap size check) is applied in that case.

What this doesn't change

• Existing decode, decode_file, decode_dummy, decode_unwrapped are untouched
• No decoder code, no macros, no decode_threaded, no packed functions
• The internal alloc_image_plain! 500M/50k panic still acts as a backstop for code paths that don't go through decode_with_limits

Public API additions

pubstructLimits{pubmax_pixels:Option<u64>,pubmax_side:Option<u64>,pubmax_input_bytes:Option<u64>,}pubfndecode_with_limits(reader:&mutdynRead,limits:&Limits) -> Result<RawImage,RawLoaderError>;pubfndecode_file_with_limits<P:AsRef<Path>>(path:P,limits:&Limits) -> Result<RawImage,RawLoaderError>;

Diff

140 insertions / 1 deletion across 2 files (src/decoders/mod.rs, src/lib.rs).

The 1 deletion is an unrelated single-line clippy fix (decoders::RawLoader::new() → RawLoader::new()) that was preventing clean compile on master.