Repository navigation
reg: three Socket._missing_ range branches are unreachable, shadowed by a wider earlier branch #841
Description
Activity
Checkable blocker: #838 merged. Not the fix itself — the PR.
gh pr view 838 -R JarryShaw/PyPCAPKit --json merged -q .merged # true == unblocked#838 already modifies
pcapkit/const/ipx/socket.py(verified:
git diff --name-only origin/main <838-head> -- pcapkit/const/ipx/lists it), so a
branch for this fix cut frommainwould conflict on the same file. The work is
therefore being prepared on top of #838's head and the PR is held until that lands,
rather than stacking a review on an unmerged branch.Also worth recording for whoever picks this up: the fix belongs in
pcapkit/vendor/ipx/socket.py, which emits the branches in IANA row order. The const
file is its output. Regeneration needs the network —Vendor.__init__calls
self._request()unconditionally — so this is a hand-edit plus a rendered-template
equivalence proof, the same approach #838 used.The mint/no-mint classification for these three branches is not part of this fix.
That is the #775 tier-2 decision ("decide from raw IANA row, not at runtime"); making
the branches reachable has to come first, or the classification has nothing to act on.- added and removed
on Sep 27, 2026 Answered on #847 about 30 seconds before this landed, so you may not have seen it —
the measurement is here.
Short version, plus the part that is specific to this registry, which is the one where the
distinction actually bites.Yes for experimental, no for dynamically assigned — and #838 already set the precedent, routing
Unassigned×43,Reserved_for_Private_Use×4,Reserved×1 andDeprecated×1 through
_unregistered_memberrather than minting.Reserved_for_Experimental_Useand
Reserved_for_Testing_Purposes_Onlystill mint and belong in that same batch.ipx/socketis the awkward one because it is the only registry whose range descriptions carry no
Unassignedat all, and the only vendor module with a module-levelRANGEStable. Of its five:range description fold into _unregistered_member?0x0020–0x003FExperimentalyes — same "no defined meaning" category 0x0001–0x0BB8Registered by Xeroxno — a positive statement about who registered it 0x4000–0x4FFFDynamically Assigned Socket Numbersno — says who assigns, not that nothing does 0x8000–0xFFFFStatically Assigned Socket Numbersno — same 0x0BB9–0xFFFFDynamically Assignedno — same One concrete coupling worth knowing before you merge #847. Folding
Experimentalin would change
Socket(0x0030)from a minted member namedExperimental_0x0030to an unregistered member carrying
that description — so #847'stest_previously_shadowed_ranges_are_reachable, which pins exactly that
name, would need updating in the same change. That is a reason to do it as the follow-up rather than
fold it into #847, not a reason to hold #847: the branch ordering this PR fixes is required either way,
since the first matching range still decides which description a value gets, minted or not.Carried into #775 tier 2 rather than opened as a separate issue. Say the word if you would rather it
were its own.- added a commit that references this issue
on Oct 2, 2026
Found while censusing the
_missing_range branches for #775. Pre-existing —not introduced by #838.
Socket._missing_tests its range branches in source order and returns on thefirst match, so three branches can never be reached:
pcapkit/const/ipx/socket.py:147Experimental0x0020-0x003F:144Registered by Xerox,0x0001-0x0BB8:153Dynamically Assigned Socket Numbers0x4000-0x4FFF:150Dynamically Assigned,0x0BB9-0xFFFF:156Statically Assigned Socket Numbers0x8000-0xFFFF:150, sameMeasured on
dd9eee846:pcapkit/vendor/ipx/socket.py:240already carries a comment noting the branchesare tested sequentially, but treats that as a description rather than a defect.
The root cause is in the vendor crawler, which emits the branches in IANA row
order rather than narrowest-range-first, so the fix belongs there and the const
file is regenerated from it. Worth checking whether any other registry with
overlapping published ranges has the same shape — this one was found by
inspection, not by a sweep.
Note the three shadowed names are also exactly the kind the #838 discussion is
about, so whichever way the mint/no-mint classification lands, these branches
need to be reachable before that classification means anything here.