netcode 1.4.3

Patch release. One fix.

netcode_generate_connect_token now bounds num_server_addresses at runtime (#173)

The two bounds on num_server_addresses were netcode_assert only. Release builds define NDEBUG, those compile to ((void)0), and the parse loops write into a 32-element stack array with no runtime bound.

This completes a decision netcode had already made rather than introducing a new policy — netcode.c states it outright ("an out of range value here must not get through in release builds where asserts compile out") and every other public entry point already pairs its asserts with a runtime check. netcode_generate_connect_token was the one that was missed.

Severity: caller-controlled, not reachable from the wire. The count comes from whatever mints tokens, so this is a precondition violation rather than a remote vulnerability — no advisory. The wire-facing path validates before every write and is unaffected.

Upgrade impact: none for valid callers. Anyone passing an out-of-range count was already in undefined behaviour; this turns that into a documented NETCODE_ERROR return.

Notes

Found while deepening the Debian autopkgtests, and confirmed by two independent review passes. A regression test is included — it installs an assert handler that returns (documented behaviour) so it can reach the release path, verifies the asserts still fire in debug builds, and verifies an in-range call still succeeds.

netcode_parse_address("[::1") returning OK was reviewed in the same pass and is deliberately unchanged — permissive in what you receive.