$ ./mcmsg_demo   [audit guest, DragonFly 6.5-DEVELOPMENT, cc 8.3, 2026-09-23 —
                  deterministic: identical output on any C99 host; full untrimmed]
E1000_VF_SET_MULTICAST_OVERFLOW = 0x00800000

=== CURRENT DragonFly ordering ===
  mc_addr_count=  5: PF-visible msgbuf[0]=0x00050003 (OVERFLOW flag LOST), uninit stack bytes sent to PF: 50 of 60
  mc_addr_count= 31: PF-visible msgbuf[0]=0x001e0003 (OVERFLOW flag LOST), uninit stack bytes sent to PF: 0 of 60
  mc_addr_count=128: PF-visible msgbuf[0]=0x001e0003 (OVERFLOW flag LOST), uninit stack bytes sent to PF: 0 of 60
=== FIXED (upstream) ordering ===
  mc_addr_count=  5: PF-visible msgbuf[0]=0x00050003 (OVERFLOW flag LOST), uninit stack bytes sent to PF: 50 of 60
  mc_addr_count= 31: PF-visible msgbuf[0]=0x009e0003 (OVERFLOW flag SET), uninit stack bytes sent to PF: 0 of 60
  mc_addr_count=128: PF-visible msgbuf[0]=0x009e0003 (OVERFLOW flag SET), uninit stack bytes sent to PF: 0 of 60
RUN_RC=0

Interpretation (DF-4794): for mc_addr_count>30 (rows 31/128) the CURRENT
DragonFly ordering hands the PF msgbuf[0]=0x001e0003 — count field 30,
OVERFLOW bit (0x00800000) LOST — so the PF programs 30 hash bits and never
enables multicast promiscuous; groups beyond those hashes silently stop
receiving. The FIXED (upstream) ordering hands 0x009e0003 — OVERFLOW SET.
("LOST" on the count=5 rows is correct behavior: no overflow at count<=30.)

Interpretation (DF-4795, count=5 rows): 50 of the 60 payload bytes (msgbuf
bytes 14..63 — words 1(partial)..15 beyond the written hash entries) are
uninitialized kernel stack transmitted verbatim to the PF by
write_posted(..., E1000_VFMAILBOX_SIZE, ...) via e1000_write_mbx_vf
(e1000_mbx.c:476-477); zeroed by the `= { 0 }` initializer (fix.diff hunk 1).