You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
EtherType: the 0x0000-0x05DC branch swallows Old Xerox 0x0101-0x01FF, so that range is unreachable #862
pcapkit/const/reg/ethertype.py's _missing_ tests 0x0000 <= value <= 0x05DC (IEEE 802.3 Length Field) at :531before0x0101 <= 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:
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.
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.
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.
Activity
JarryShaw commentedon Sep 27, 2026
Blocked on #861. The fix touches
pcapkit/const/reg/ethertype.pyandpcapkit/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 withgh pr view 861 --json state,mergedAt.JarryShaw commentedon Sep 27, 2026
Unblocked — #861 merged at 22:06:39Z as
70fa92010, and it was the only gate. It ownedpcapkit/const/reg/ethertype.pyandpcapkit/vendor/reg/ethertype.py, which this fix has to touch.Re-verified rather than assumed, on
mainat the merge commit:ethertype.py:531still tests0x0000 <= value <= 0x05DCbefore:534's0x0101 <= value <= 0x01FF, so the Old Xerox branch remains unreachable for every value it covers. #861 converted that branch's body to_unregistered_memberbut did not reorder the two range tests, which is exactly what it said it was doing.Dispatching a worker now.
blockedremoved.fix(const,vendor): test the narrower Old Xerox range before the wider…
fix(const,vendor): test the narrower Old Xerox range before the wider…
test(corekit): retarget the last #864 default-in-unassigned-range ass…
fix(corekit): stop EnumRegistry.get's default from minting (#868)
fix(const,vendor): stop EtherType and Socket minting on an unrecognis…