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.

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

    bugSomething isn't working

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions