Repository navigation
fix: six .get implementations mint unknown keys at a shared -1, so the second aliases to the first #880
Description
Activity
Checkable blocker: #877's per-class verdicts.
gh issue view 877 -R JarryShaw/PyPCAPKit --json state
Four of this defect's six sites are the
mh.pyenums, and #877's audit found each of them cites a document saying the opposite of what it does — e.g.mh.py:576: "IANA keeps no registry of them". Under the owner's ruling on #877 ("make them immutable - unless RFC/IANA says otherwise") those four should not mint at all, which makes "give each unknown key a unique value" the wrong fix for them and "stop minting, return a non-registering member or raise" the right one. The other two —ProcedureCodeandProtocolIE— are genuinely open per 3GPP TS 38.413, so they do want a per-key unique value rather than the shared-1.So the six sites want two different fixes, and which one applies to the
mh.pyfour is decided on #877, not here. Splitting a single six-site defect across two PRs to avoid waiting would cost more than it saves, so this staysblockeduntil #877 settles those rows.What is not blocked and can be done the moment anyone wants it:
LocalizedRoutingStatus.getandLMAAddressCode.gethave zero callers repo-wide, tests included, so two of the four mint sites can simply be deleted rather than redesigned.- added 6 commits that reference this issue
on Sep 29, 2026 All six sites are resolved. Closing, with one vestigial leftover noted rather than left silent.
The four
mh.pyenums landed in #889 (fde4cb20c);ProcedureCodeandProtocolIElanded in #899 (d90223bf5) as pycrate-sourced generated registries per your ruling. And the blocker recorded on this issue — "#877's per-class verdicts" — is discharged: #877 is ruled, its phase 1 merged as #906 (c50f442db), and the registry-wide case audit continues as #903.I checked for a seventh site rather than trusting the count, because
git grepstill finds the-1default:pcapkit/const/pcapng/option_type.py:238 def get(key, default: 'int' = -1, *, namespace='opt') pcapkit/vendor/pcapng/option_type.py:148 (the crawler template for the above)Measured on
origin/main, andOptionTypeis clean on both halves of this defect:before: members=40 values=40 get(60000) -> opt_unknown [60000] registered=False get('zz_bogus_option') -> zz_bogus_option [-1] registered=False after : members=40 values=40 names added: [] values added: [] is -1 a registered value? FalseNo minting — neither lookup table grows. And no aliasing, which is the part I nearly got wrong: the
reprrenders as<OptionType.zz_one: -1>and I first read that as the shared sentinel, but the actual value is'zz_one [-1]'— the key is embedded, so two different unknown strings stay distinct:get("zz_one") -> value='zz_one [-1]' get("zz_two") -> value='zz_two [-1]' distinct values? True both == -1? False int path: 'opt_unknown [60001]' vs 'opt_unknown [60002]' distinct? TrueSo the
-1survives only as a signature default that is never used as a value — cosmetic, and misleading in exactly the way that cost me a second look. It is worth removing, but it is not this defect and it does not keep the issue open. Anyone touchingpcapng/option_type.pynext should drop it, in the crawler template atvendor/pcapng/option_type.py:148rather than the generated file, or the next regeneration restores it.Closing. Reopen if you read the vestigial default as in scope.
Six
.getimplementations mint an unknownstrkey at a shared sentinel value-1, so the second unknown key silently resolves to a member named after the first. Measured onmainatedc1b32e0:aenumtreats the duplicate-1as an alias request, socls['bogus_two']returns a member whosenameisbogus_one. A name that lies about itself.It also bypasses the class's own stated range invariant. All four
mh.py_missing_methods reject anything outside0 <= value <= 255, yet after oneget('bogus_one'):extend_enumwith an explicit value never consults_missing_, sogetinstalls a member the class itself declares invalid.Six sites, one shape —
protocols/internet/mh.py::{FastBindingAcknowledgmentStatus, IPv6AddressPrefixCode, LocalizedRoutingStatus, LMAAddressCode}andprotocols/application/ngap.py::{ProcedureCode, ProtocolIE}. Themh.pyfour returnCls[key]after extending and thengap.pytwo returnextend_enum(...)directly, but both land on the same aliased member, so the divergence saves neither.Note the two families want different fixes, per #877's audit: the four
mh.pyenums cite documents that say "IANA keeps no registry of them" (e.g.mh.py:576), so they should not be minting at all;ProcedureCode/ProtocolIEare genuinely open per 3GPP TS 38.413 and need a per-key unique value rather than a shared sentinel.LocalizedRoutingStatus.getandLMAAddressCode.gethave zero callers repo-wide and can simply go.Two existing tests pin the current minting and will need re-pointing:
tests/protocols/internet/test_mh_unit.py:1530and:1534assertget('Vendor_specific', 200) == 200.