Handling of Signaling NaN in pow functions

Lorrens Pantelis lorrens.pantelis@student.uhasselt.be
Wed May 21 16:17:28 GMT 2025


Dear libc mailing list people,

I’m currently working on simulating non-determinism in floating-point
operations within Rust’s Miri interpreter
(https://github.com/rust-lang/miri). Specifically, we simulate
imprecision by adding a 16 ULP relative error to the outputs of some
floating-point operations. However, for certain operations (e.g.,
involving fixed outputs), this is not applicable. While handling these
cases, we encountered interesting behavior with the `pow` function
between glibc and musl.

The operation `pow(x, 0)` is defined differently between the IEEE 754
standard and the C standard:
- IEEE 754: `pow(x, 0) = 1` if `x` is not a sNaN.
- C standard: `pow(x, 0) = 1` for all `x`, including sNaNs.

When testing the behavior of `pow(SNaN, 0)`:
- glibc returns a quieted NaN — this seems to align with IEEE 754, but
not strictly.
- musl returns `1`, matching the C standard.

The discussion we had in the Rust community is linked here for reference:
https://github.com/rust-lang/rust/pull/138062#discussion_r2033840426

We’re curious to understand the rationale behind glibc's choice. Is
there a guiding principle or policy you follow when handling sNaNs in
math functions?

Thank you for your time and insights!

Best regards,
Lorrens Pantelis


More information about the Libc-help mailing list