lightcraft

mirror of https://github.com/storytold/lightcraft.git synced 2026-11-01 14:07:34 -06:00

Files

T

insideTheFluxandClaude Opus 5.5 fbbf5c0c53 LR-IMP-FORMATS: GIF and BMP coverage comes from the pixel data, not the file's length (#2553 )

Padding counted as pixel data: a file padded with junk could still claim a canvas up to
max_pixels, which the decoder allocates before it finds the data missing.

- Uncompressed BMP: the rows the header describes (bits per pixel, 4-byte row padding) must
  all be present after the pixel-data offset; the decoder reads every row in full.
- RLE BMP: the commands are walked as the decoder paints them (runs clipped at the row's end,
  end-of-row, delta, end-of-bitmap); bytes after the end draw nothing.
- GIF: the first frame's LZW codes are walked up to the end code, keeping only the length of
  each table string; data sub-blocks after the end code draw nothing.

A canvas the data leaves mostly blank stays limited to 4 MP. New tests: one padded file per
case (all four were accepted before), and the LZW walk against frames the encoder wrote.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016TuX1qw9ieyuJ1ZFrrUxzc

2026-10-24 07:46:31 -07:00

bench.rs

CI: one test binary per crate, line tables only, one WASM check (#2710 )

2026-10-23 13:34:30 -04:00

corpus.rs

CI: one test binary per crate, line tables only, one WASM check (#2710 )

2026-10-23 13:34:30 -04:00

float_tiff.rs

CI: one test binary per crate, line tables only, one WASM check (#2710 )

2026-10-23 13:34:30 -04:00

fuzz.rs

LR-IMP-FORMATS: GIF and BMP coverage comes from the pixel data, not the file's length (#2553 )