# C++ backup endpoint parsing review A malformed backup key can replace a legitimate endpoint. The C++ parser accumulates the suffix of `SocketConnectHost` / `SocketConnectPort` in a signed `int` without checking overflow. In an optimized reproduction, `SocketConnectHost4294967297=unexpected.example` replaced backup slot 1. Clang UBSan independently stopped at the overflowing `429496729 * 10` expression. This is configuration parsing, not a finding that network messages can change settings. ## Correction and regressions The parser now bounds each accumulation step to the supported backup range, 1 to 9, before another multiply can overflow. Unsupported keys follow the existing unknown-key diagnostic path. That also makes an unsupported index such as 10 an unknown key rather than a silently consumed setting: safe-mode configuration can proceed with the diagnostic, while fast mode or strict unknown-key rejection refuses it. Leading zeroes and sparse supported backup slots retain their existing C++ behavior. Regressions apply 13 malformed suffixes to both host and port keys, preserving an existing endpoint and checking safe, fast and strict diagnostics. They cover supported slots, leading zeroes, 4,096-digit inputs, sparse-slot fallback and a real configuration-file load containing the aliasing suffix. New fixtures use the configured temporary directory; the full architecture suite runs from a private build-root runtime directory. No send, receive, synchronization or NIC configuration code changed. The first full-suite run stopped before the new regression at a pre-existing assertion that `file` mapped to `mmap`. The portable-file work already deliberately maps it to `async-file`; the assertion is corrected to match, without changing that production mapping. The failing log and baseline assertion are retained. ## Evidence and scope The final regressions passed the optimized GCC 14/LTO architecture and reconnect-driver suites after merging the concurrent portable-file changes. The full architecture suite and standalone overwrite probe also passed Clang 21 ASan/UBSan with leak detection. These checks include explicit ASCII-only suffix classification and non-ASCII/trailing-space inputs. Both changed C++ files passed the public-export scan with zero findings. The corrected header has SHA-256 `d0c2d9ebbf3dd255956c691548274ca5ba36c1116781db552b9c64176cd92768`; the architecture test has SHA-256 `90710462258867db532e1a325a275d575e29a118da7a9679f2fb16bcdc52d463`. `~/archive/libhft/config-endpoint-overflow-review-20261002/` keeps the original standalone source and failing log, scripts, exact patch and source pins. The baseline header at `f0fd8984d` has SHA-256 `4af03434cc29686e6b9c7023a49cfe78787b6f32362806409c9d35039a5d4269`. The direct configuration loader paths in Java and .NET enumerate supported suffixes instead of accumulating an arbitrary numeric suffix. This reproduction therefore establishes the C++ flaw only; no equivalent managed-loader defect is claimed. ## Export check interpreter compatibility The final verification initially stopped at the export scan, after the C++ tests passed. A concurrent release-metadata helper imported Python 3.11's `tomllib` unconditionally, so this host's Python 3.9 could not start even a non-TOML scan. The helper now makes that dependency optional at import time; Rust release metadata still fails closed and asks for Python 3.11 or newer when it is absent. C++ tag validation and Java/.NET XML metadata retain their checks. Six regressions simulate an unavailable TOML parser even on a newer interpreter; all six passed on Python 3.9. The final selected export run passed 73 tests, including those six and the existing non-TOML metadata, closure, scrub and disposable local-commit checks; both actual C++ scans also passed. The six tests are included in the export self-test's normal test discovery. This does not establish that the complete Rust release metadata suite runs on Python 3.9: its pre-existing Python 3.11 requirement remains. One intermediate test invocation failed because module-style discovery did not add `tools` to the import path. Running the established test-file entry point resolved that invocation error; no unrelated import-path code was changed.