bug: common_stereo_paths_preserve_general_fold_bits relies on unspecified NaN bits

[bitbloxhub]

Drafted by ChatGPT (GPT-5.6-Sol)

Before filing

• I searched existing issues for a duplicate.
• I can reproduce this.

OpenMeters version

1.14.0

Environment

• Architecture: aarch64-linux
• Build/package environment: Nix

Steps to reproduce

1. Build/test OpenMeters 1.14.0 on aarch64-linux.
2. Run the test suite.
3. dsp::tests::common_stereo_paths_preserve_general_fold_bits fails (maybe, it might be flaky, IDK).

Expected behavior

The optimized stereo paths should be checked for the same floating-point behavior as the general fold without requiring an exact NaN bit pattern.

Actual behavior

The test compares results with to_bits() and fails when two valid NaNs have different payload bits.

For the 0x7fc0_1234 test input, the two paths produce:

actual:   0x7fc01234
expected: 0x7fc00000

Both are valid quiet NaNs. Rust does not guarantee preservation of NaN bit patterns across floating-point arithmetic:
https://doc.rust-lang.org/core/primitive.f32.html#nan-bit-patterns

Logs or crash output

---- dsp::tests::common_stereo_paths_preserve_general_fold_bits stdout ----

thread 'dsp::tests::common_stereo_paths_preserve_general_fold_bits' panicked at src/dsp.rs:624:17:
assertion `left == right` failed
  left: [2143294004, 2143294004]
 right: [2143289344, 2143294004]

failures:
    dsp::tests::common_stereo_paths_preserve_general_fold_bits

Additional context

The test can keep exact bit comparison for non-NaN values, including signed zero, while only requiring NaN results to remain NaN:

if expected.is_nan() {
    assert!(actual.is_nan());
} else {
    assert_eq!(actual.to_bits(), expected.to_bits());
}

It may also make sense to rename the test to common_stereo_paths_match_general_fold, since exact bit preservation is not a portable invariant for arithmetic-produced NaNs.

Full logs: https://github.com/magnetophon/nixpkgs-review-gha/actions/runs/33596708123/job/100141537168#step:6:2380

[httpsworldview]

Thanks. I don't usually test on ARM, and I don't use it myself, so thanks for bringing this up. Tested in a QEMU box, but let me know if that doesn't work.

[bitbloxhub]

I don't use ARM myself either, but @magnetophon, my co-maintainer on the Nixpkgs side, has nixpkgs-review-gha running for the package, so it caught that by building on an ARM runner during an autoupdate. Regardless, that fix looks good. Thanks!