Skip to content

gamut-core: shared byte-tiling primitive for deconstruct/segments #500

Description

@justin13888

Summary

Four crates now implement the same "every byte of the input maps to exactly one typed segment" report shape independently: gamut_isobmff::segments, gamut_heic's container parse, gamut_dng::deconstruct, and gamut_png::deconstruct (#224, PR #485). Each carries its own Segment { range, kind }, its own "contiguous, non-overlapping, covers 0..len" predicate (is_fully_classified and its twins), and its own test helper re-deriving that predicate.

Proposal

A gamut-core primitive for the format-agnostic part:

  • a generic Segment<K> over a caller-supplied kind enum, keeping the existing per-format kinds;
  • the tiling predicate written once (fn covers(segments, len) -> bool), with its negative cases (gap, overlap, empty segment, short/long tail) tested once as unit tests beside it — today each crate builds those malformed tilings by hand in its own inline tests;
  • optionally the Range<usize>-chaining walker the four walks share.

Why gamut-core

It has no format knowledge and every deconstruct already depends on it. gamut-core's authority row in docs/testing.md is property, and "a tiling covers 0..len" is a law with no oracle, so it fits the crate's testing posture.

Out of scope

Changing any format's segment kinds or report figures. This is a consolidation of the shape and its predicate, not of the walks.

Raised as design question 9 in the review of PR #485; recorded there as filed rather than done because it touches four crates and is not the PR's subject.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions