Support 32-bit machines

[kampersanda]

What

Removes the 64-bit-only restriction: the compile_error! in lib.rs and the #![cfg(target_pointer_width = \"64\")] attributes on 14 modules are gone, and the handful of real dependencies on the pointer width are fixed.

Why

The restriction turned out to be almost entirely incidental. Deleting the cfg gates and building for a 32-bit target produced only three compile errors, all of them broadword constants. Everything else was already stored in explicit widths (Vec<u64>, Vec<u16>, Vec<u8>), with usize used for lengths and positions as it should be.

What actually depended on the pointer width

• broadword — the 64-bit step constants (ONES_STEP_8, MSBS_STEP_9, …) were typed usize, so they overflowed at compile time on a 32-bit target. Now u64, along with the helpers that consume them. On a 64-bit machine the two types are identical, so this is a no-op there.
• Rank9SelIndex::block_rank_pairs — packs seven 9-bit subranks into one word, which does not fit in a 32-bit usize. Now Vec<u64>.
• DArrayIndex::block_inventory — bit positions stored as isize; beyond 2^31 bits on a 32-bit machine they would wrap into the negative overflow marker and silently corrupt select. Now Vec<i64>.
• EliasFanoBuilder::push — val as usize >> low_len cast before shifting, truncating the value. Now shifts before casting. (Found by an actual 32-bit test run, not by reading.)
• EliasFano::delta — computed the delta in usize, which overflows once low_len >= 32. Now computes in u64. (Also found by running.)

Serialization

usize and isize are now serialized as fixed 64-bit little-endian integers instead of native-width ones, so the format no longer depends on the machine.

• Backward compatible. The bytes are unchanged from what 0.9.1 writes on a 64-bit machine, so existing serialized data stay readable.
• Portable. A file written on a 64-bit machine reads on a 32-bit one and vice versa.
• Deserializing a value that does not fit in usize of the machine fails with SucdsError::InvalidArgument rather than truncating silently.

Verification

Runtime behavior was checked on wasm32-wasip1, a genuine 32-bit target, run under Node's WASI.

Check	Result
Unit tests on wasm32-wasip1 (32-bit)	90/90 pass
Tests + doctests on 64-bit (default / intrinsics / no-default-features)	90 + 101 pass each
cargo check --target i686-unknown-linux-gnu --all-targets (stable and 1.62.0)	pass
cargo build --no-default-features --target thumbv7em-none-eabi (stable and 1.62.0)	pass
x86_64-unknown-none (existing no_std job)	pass
MSRV 1.62.0	pass
cargo fmt / clippy nursery -D warnings / cargo doc -D warnings	clean

Serialized bytes and query results were compared across three builds — 0.9.1 on 64-bit, this branch on 64-bit, and this branch on 32-bit — over BitVector, Rank9Sel, DArray, SArray, CompactVector, DacsByte, DacsOpt, PrefixSummedEliasFano, EliasFano, and WaveletMatrix. All three outputs are byte-identical.

CI

• New test-32bit job: builds and runs the tests for i686-unknown-linux-gnu. i686 binaries execute natively on the x86_64 runner, so the tests really run with a 32-bit usize rather than only cross-compiling. -C target-cpu=native is deliberately not set for the intrinsics run, since the host is x86_64. Stable only — the MSRV is covered by the 64-bit test job, and nothing here depends on the language version.
• The no-std job also builds for thumbv7em-none-eabi, covering no_std and a 32-bit pointer width at once.

Note: the i686 job itself has not been executed yet — it was developed on macOS, where no Linux runner is available. It is compile-checked on both toolchains, and the 32-bit runtime behavior is covered by the wasm32 run above. This PR's CI is its first real execution.

Remaining limitations (documented in the README and crate docs)

• On a 32-bit machine each structure is bounded by usize, i.e. fewer than 2^32 stored bits or integers.
• Broadword operations on 64-bit words are emulated on 32-bit machines and are therefore slower.
• No 64-bit performance regression is expected: usize and u64 are the same type there and the memory layout is unchanged. Benchmarks have not been run.

🤖 Generated with Claude Code