feat: speed up incoming packet parsing - #1830

Merging this PR will improve performance by 43.28%

⚡ 2 improved benchmarks
✅ 22 untouched benchmarks

Performance Changes

_{Comparing speed_up_incoming_parser (59acf2c) with master (e63bf6f)}

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 99.87%. Comparing base (28f8047) to head (59acf2c).
⚠️ Report is 2 commits behind head on master.

@@           Coverage Diff           @@
##           master    #1830   +/-   ##
=======================================
  Coverage   99.86%   99.87%           
=======================================
  Files          33       33           
  Lines        3839     3883   +44     
  Branches      553      567   +14     
=======================================
+ Hits         3834     3878   +44     
  Misses          3        3           
  Partials        2        2           

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

Just waiting for ASAN locally

local ASan 50,000 hostile packets + all 14 audit boundary packets, zero sanitizer reports.

@bdraco: local ASan 50,000 hostile packets + all 14 audit boundary packets, zero sanitizer reports.

Matches static audit. Traced all buffer reads independently: header, questions, record header, SRV, character string, string, NSEC bitmap, name fast path, label pointer. Each guarded before dereference. Label slice correctly stays on self.data, avoiding pointer over-read.

One gap: fuzz strategies cap at _MAX_MSG_ABSOLUTE + 256, roughly 9 KiB. ASan corpus likely same range. Nothing reaches offsets near 65535, where no-wrap argument for MAX_MSG_LEN matters. Worth one 65530-byte packet with record header at tail.

Previous review — superseded by a newer review below.

1. Pickle refusal + readonly data are user-visible restrictions on a re-exported class
   src/zeroconf/_protocol/incoming.py:140-143

Nobody is pickling DNSIncoming, that would be a crazy use case. Its not intended to be a public API. This is an internal safety

@bdraco: > 1. Pickle refusal + readonly data are user-visible restrictions on a re-exported class

Fair — dropping that finding. Grepped repo: nothing pickles or copies DNSIncoming, so no in-tree breakage. Only note: __reduce__ also blocks copy.copy and copy.deepcopy, which your test already pins. Won't re-raise.

PR Review — feat: speed up incoming packet parsing

Approving. All three notes from my previous pass are now addressed or dismissed by the author; nothing blocking remains.

Re-verified against the current head (the branch moved from aa41716 to 1f07f73): every raw-buffer read is still bounds-checked before dereference — _read_header (+12), _read_questions (+4), _read_others (+10), SRV (+6), _read_character_string (length byte then slice), _read_string, _read_bitmap (record end plus per-window bitmap_end > end), the _read_name fast path (+2), and both buf[off]/buf[off + 1] in _decode_labels_at_offset. The label slice deliberately stays on self.data so Python's truncating slice, not a pointer over-read, handles a label running past the end. I also re-checked that an oversized packet can't reach a read through answers(): _initial_parse raises before _read_header, so the section counts stay 0 and _read_others iterates zero times — which test_oversized_message_is_rejected pins.

What changed since the last review, and how it lands:

• Suggestion ＃3 (no fuzzing near the 64 KiB boundary) — resolved by e0abe0b. I hand-checked the offset math in test_records_near_the_size_cap_never_raise: tail_record is 20 bytes, skip_len = total - 43 ∈ [65460, 65492], and record 2's name, header, SRV fixed fields, and target pointer are all parsed against the cap. One residual coverage gap noted inline (non-blocking).

• Suggestion ＃2 (unstated key-range invariant) — resolved for the load-bearing half: the comment at incoming.py:503-505 now states that entries exist only at offsets inside the packet, so an out-of-range link can only miss. The duplicated >= 0xC0 / (length & 0x3F) * 256 + ... pointer arithmetic in two places remains; not worth blocking, just keep the two sites in step.

• Suggestion ＃1 (pickle refusal + readonly data) — dismissed per @bdraco: "Nobody is pickling DNSIncoming, that would be a crazy use case. Its not intended to be a public API. This is an internal safety." Not re-raised.

• One non-blocking suggestion: the new boundary fuzz test can only ever hit the record-drop path, so a clean decode at the cap goes unexercised.

🟢 Suggestions

rdlength=st.one_of(st.just(8), st.integers(min_value=0, max_value=0xFFFF)),

    rdlength=st.integers(min_value=0, max_value=0xFFFF),

Checklist

• Every raw-buffer read is bounds-checked before dereference
• Oversized input cannot reach a read via the lazy answers() path
• No unsigned arithmetic wrap on offset/length math, now fuzzed at the cap
• Compression-pointer loop and depth detection preserved by the lazy set
• Name string cache cannot return an unvalidated or out-of-range decode
• Parsing still never raises out of the constructor for hostile input
• .pxd updated in step with the cdef class layout and signatures
• New branches covered by tests — suggestion ＃1
• Diff matches the PR description with no scope creep

Automated review by Kōan (Claude) HEAD=1f07f73 7 min 6s