[Bug 214815] pow(3): underflow result can be -0.0

[bugzilla-daemon@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=214815

--- Comment #1 from Alejandro Colomar (man-pages) (alx.manpages@gmail.com) ---
[[CC += glibc]]

Hello,

On 10/26/21 12:33 AM, bugzilla-daemon@bugzilla.kernel.org 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@kernel-bugs.osdl.org
>            Reporter: mwelinder@gmail.com
>          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.