Zig Version
0.16.0-dev.2609+d2c862e6f
Steps to Reproduce and Observed Behavior
Before 7aae7dd3f4,
conststd=@import("std");externfnpow(f64,f64)callconv(.c)f64;pubfnmain()!void{constx=0.85;consty=4.019250798563942;constresult=pow(x,y);std.debug.print("{x}\n",.{result});}$ zig run test.zig -lc -target native-native-musl
produced:
0x1.0a6ead2391036p-1
After this commit, where we replaced the libc pow() with the stdlib std.math.pow implementation, it returns:
0x1.0a6ead2391035p-1
While I believe that both of these results are valid interpretations of pow(), given that the function is not standardized and subject to rounding (it is one UOP off of the actual correct answer), there are many usecases in the Real World where this difference matters.
Changing the behaviour underneath the users like this will end very poorly.
Expected Behavior
The libc behaviour should not change.
### Zig Version
0.16.0-dev.2609+d2c862e6f
### Steps to Reproduce and Observed Behavior
Before https://codeberg.org/ziglang/zig/commit/7aae7dd3f4d4b85837369fa591e566ae812f87dc,
```zig
const std = @import("std");
extern fn pow(f64, f64) callconv(.c) f64;
pub fn main() !void {
const x = 0.85;
const y = 4.019250798563942;
const result = pow(x, y);
std.debug.print("{x}\n", .{result});
}
```
```
$ zig run test.zig -lc -target native-native-musl
```
produced:
```
0x1.0a6ead2391036p-1
```
After this commit, where we replaced the libc pow() with the stdlib `std.math.pow` implementation, it returns:
```
0x1.0a6ead2391035p-1
```
While I believe that both of these results are valid interpretations of pow(), given that the function is not standardized and subject to rounding (it is one UOP off of the actual correct answer), there are many usecases in the Real World where this difference matters.
Changing the behaviour underneath the users like this will end very poorly.
### Expected Behavior
The libc behaviour should not change.