Skip to content

fix(rules): leading-zero numeric-string enum values may corrupt in Rule::in (inline-enum path, sibling of #145) #167

Description

@benjamineckstein

Discovered while implementing #145. #145 fixed the BACKED-ENUM-CLASS path (EnumEmitter) so a "01"/"040000" enum value is no longer mangled into an int. The SIBLING path was out of scope and may carry the same defect: an inline property enum that the generator emits as a Rule::in([...]) (or in: rule) rather than a backed enum class.

Candidate (reported by the #145 implementer, needs a confirming test): github.json's git-tree mode enum, e.g. ["100644","040000","120000","160000"]. If RulesBuilder emits these as PHP int literals (Rule::in([100644, 040000, ...])), then 040000 is a PHP octal literal (= 16384) — a silent value corruption. If emitted as quoted strings ('040000') it is correct.

Acceptance.

  • Add a test pinning the exact emitted rule for a leading-zero numeric-string enum on the inline/Rule::in path.
  • Ensure values emit as faithful string literals ('040000'), never bare/octal int literals.
  • Fix RulesBuilder if corrupted; no corpus drift unless a corpus spec is actually being de-corrupted (then audited rebaseline).

Filed from the audit work stream; sibling of #145.

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't working

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions