Found via
The v0.4 release CI run's Windows binary job (release-binaries-windows): https://github.com/sidick/volamos/actions/runs/34688695402/job/103540225429
The warnings
warning: constant `FIONREAD` is never used
warning: constant `FD_ACCEPT` is never used
warning: constant `FD_CONNECT` is never used
warning: constant `FD_READ` is never used
warning: constant `FD_WRITE` is never used
warning: constant `FD_ERROR` is never used
warning: constant `FD_CLOSE` is never used
warning: fields `servent_allocs` and `protoent_allocs` are never read
warning: constant `FD_SET_BYTES` is never used
warning: function `fd_set_test` is never used
warning: function `fd_set_zero` is never used
warning: function `fd_set_add` is never used
warning: `volamos-core` (lib) generated 12 warnings
Not a functionality gap
bsdsocket.rs's own module doc already documents that bsdsocket.library's socket support (including WaitSelect) is #[cfg(unix)]-only by design, with Windows deliberately returning EOPNOTSUPP rather than a best-effort guess. This is intentional, existing, documented behavior -- not something these warnings reveal as new.
The actual issue: cosmetic, missing #[cfg(unix)]
The warnings' items (FIONREAD, FD_ACCEPT/FD_CONNECT/FD_READ/FD_WRITE/FD_ERROR/FD_CLOSE, FD_SET_BYTES, fd_set_test/fd_set_zero/fd_set_add, BsdSocketState::servent_allocs/protoent_allocs) are defined unconditionally in crates/volamos-core/src/bsdsocket.rs, but only ever used from within code that's already #[cfg(unix)]-gated -- so on a Windows build they're legitimately dead. Only CI's Windows binary job surfaces this (the test/compare jobs only run on Linux/macOS), so it's gone unnoticed until now.
Fix direction
Add #[cfg(unix)] to these specific item definitions (or to a wrapping mod/block if that's cleaner), matching the existing #[cfg(unix)] gating already applied to their call sites, so the Windows build compiles clean without changing any actual behavior.
🤖 Found via the v0.4 release CI run, filed by Claude Code at the user's request
https://claude.ai/code/session_0171vaHw8HbkiLzUph9bAA2p
Found via
The v0.4 release CI run's Windows binary job (
release-binaries-windows): https://github.com/sidick/volamos/actions/runs/34688695402/job/103540225429The warnings
Not a functionality gap
bsdsocket.rs's own module doc already documents thatbsdsocket.library's socket support (includingWaitSelect) is#[cfg(unix)]-only by design, with Windows deliberately returningEOPNOTSUPPrather than a best-effort guess. This is intentional, existing, documented behavior -- not something these warnings reveal as new.The actual issue: cosmetic, missing
#[cfg(unix)]The warnings' items (
FIONREAD,FD_ACCEPT/FD_CONNECT/FD_READ/FD_WRITE/FD_ERROR/FD_CLOSE,FD_SET_BYTES,fd_set_test/fd_set_zero/fd_set_add,BsdSocketState::servent_allocs/protoent_allocs) are defined unconditionally incrates/volamos-core/src/bsdsocket.rs, but only ever used from within code that's already#[cfg(unix)]-gated -- so on a Windows build they're legitimately dead. Only CI's Windows binary job surfaces this (thetest/comparejobs only run on Linux/macOS), so it's gone unnoticed until now.Fix direction
Add
#[cfg(unix)]to these specific item definitions (or to a wrappingmod/block if that's cleaner), matching the existing#[cfg(unix)]gating already applied to their call sites, so the Windows build compiles clean without changing any actual behavior.🤖 Found via the v0.4 release CI run, filed by Claude Code at the user's request
https://claude.ai/code/session_0171vaHw8HbkiLzUph9bAA2p