https://bugzilla.kernel.org/show_bug.cgi?id=214815 --- Comment #1 from Alejandro Colomar (man-pages) (alx.manpages@xxxxxxxxx) --- [[CC += glibc]] Hello, On 10/26/21 12:33 AM, bugzilla-daemon@xxxxxxxxxxxxxxxxxxx wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=214815 > > Bug ID: 214815 > Summary: pow(3): underflow result can be -0.0 > Product: Documentation > Version: unspecified > Hardware: All > OS: Linux > Status: NEW > Severity: low > Priority: P1 > Component: man-pages > Assignee: documentation_man-pages@xxxxxxxxxxxxxxxxxxxx > Reporter: mwelinder@xxxxxxxxx > Regression: No > > The pow(3) man pages as found here: > https://man7.org/linux/man-pages/man3/pow.3.html says... > > "If result underflows, and is not representable, a range error occurs, and > 0.0 > is returned." > > That fails to take signs into account. pow(-1e-100,5) produces -0.0, not 0.0 > > Suggested wording: "... and 0.0 with the appropriate sign is returned." > I checked the C standard, and it doesn't mention what to do in this case (or I couldn't find it). I also checked POSIX; it says that pow() shall return 0.0 in this case (doesn't specify the sign; should we assume +0.0, or is it a lazy/buggy wording for +/-0.0?). Finally, the glibc manual doesn't mention this special case. So, is this a bug in glibc? Or is it a bug in POSIX? Or is it an undocumented glibc extension? I checked FreeBSD's manual, and it doesn't mention this special case either. Thanks, Alex -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
