[omrzk]

SockAddr::unix accepts pathname bytes containing NUL, which operating systems can truncate and the standard library rejects. Reject those pathnames with InvalidInput in both constructor backends. Preserve the existing leading-NUL address behavior, including Linux abstract names containing additional zero bytes.

Retain a fallible as_unix conversion for addresses initialized from raw storage: a full-size, null-terminated sockaddr_un can still include padding NULs in the pathname exposed by as_pathname. The new raw-storage fixture covers that conversion boundary.

Fixes #681.

Validation: constructor rejection fails on the previous PR head and passes after the change; ordinary/non-UTF-8 paths, empty/unnamed addresses and abstract names are preserved. Default and all-feature suites pass in debug and release (11 unit tests; 47 default or 82 all-feature integration tests; 7 or 8 doc tests). Formatting, all-target/all-feature Clippy with warnings denied, docs and all-target/all-feature Windows MSVC and FreeBSD compile checks pass. Runtime tests were run on Linux; the Windows/FreeBSD checks were compilation only.

[Thomasdezeeuw]

I don't think is the right approach, we should look into disallowing the creation of address with internal null bytes. Most OS, being C based, don't deal well with internal null bytes.

[omrzk]

Updated the existing branch to reject NUL bytes in pathname addresses in both constructor backends. Leading-NUL addresses retain their existing behavior, including interior zeros in Linux abstract names.

I kept the fallible as_unix conversion because raw initializers can still provide a full-size null-terminated sockaddr_un whose padding is included by as_pathname; a separate raw-storage regression covers that case. The constructor regression fails on the previous PR head and passes with this change. Final test and cross-compilation results are recorded in the updated description.