Skip to content

EtherType: the 0x0000-0x05DC branch swallows Old Xerox 0x0101-0x01FF, so that range is unreachable #862

Closed

Description

@JarryShaw

pcapkit/const/reg/ethertype.py's _missing_ tests 0x0000 <= value <= 0x05DC (IEEE 802.3 Length Field) at :531 before 0x0101 <= value <= 0x01FF (Old Xerox Experimental) at :534. The second range is wholly contained in the first, so the Old Xerox branch at :534-537 is unreachable for every value it covers:

EtherType(0x0101).name  ->  'IEEE802_3_Length_Field_0x0101'   # expected Old_Xerox_...

Measured on main and confirmed unchanged by #861's cross-review, which found it while verifying that PR's Old Xerox conversion — that conversion is correct in source and simply never runs.

Same shape as #841 (IPX socket range ordering): the generated order follows the source table's row order, and a narrower range listed after a wider one is dead. The fix belongs in the generator, pcapkit/vendor/reg/ethertype.py, so a regeneration cannot undo it — but unlike #841 the range bounds are not literals in the crawler, so where the ordering is decided needs establishing first.

This is a real behaviour change (a code that resolves to one name today would resolve to another), so it wants its own PR rather than being folded into #861 or #775.

Activity

  1. added
    bugIssues reporting a defect (set by the bug report template; a default, not an assessment)
    constRegenerated IANA or vendor constant tables; members keep their numeric values
    blockedDeferred pending another issue or decision; see the last comment for what unblocks it
    on Sep 27, 2026
  2. JarryShaw commented on Sep 27, 2026

    @JarryShaw
    OwnerAuthor

    Blocked on #861. The fix touches pcapkit/const/reg/ethertype.py and pcapkit/vendor/reg/ethertype.py, both of which #861 is currently rewriting; starting here first would put the two changes in conflict over the same _missing_ body. Unblocks the moment #861 merges — check with gh pr view 861 --json state,mergedAt.

  3. removed
    blockedDeferred pending another issue or decision; see the last comment for what unblocks it
    on Sep 27, 2026
  4. JarryShaw commented on Sep 27, 2026

    @JarryShaw
    OwnerAuthor

    Unblocked — #861 merged at 22:06:39Z as 70fa92010, and it was the only gate. It owned pcapkit/const/reg/ethertype.py and pcapkit/vendor/reg/ethertype.py, which this fix has to touch.

    Re-verified rather than assumed, on main at the merge commit: ethertype.py:531 still tests 0x0000 <= value <= 0x05DC before :534's 0x0101 <= value <= 0x01FF, so the Old Xerox branch remains unreachable for every value it covers. #861 converted that branch's body to _unregistered_member but did not reorder the two range tests, which is exactly what it said it was doing.

    Dispatching a worker now. blocked removed.

  5. added
    wipWork in flight - a covering PR is open or an agent is actively on it
    on Sep 27, 2026
  6. added 2 commits that reference this issue on Sep 27, 2026
    8901e28
    7f7b24e
  7. removed
    wipWork in flight - a covering PR is open or an agent is actively on it
    on Sep 28, 2026
  8. added this to the 1.5 milestone on Oct 6, 2026
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

    bugIssues reporting a defect (set by the bug report template; a default, not an assessment)constRegenerated IANA or vendor constant tables; members keep their numeric values

    Projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions