public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
* Re: nextafter underflow and errno in Glibc
       [not found] <PR0P264MB07942F010016373449ED98D6C0B49@PR0P264MB0794.FRAP264.PROD.OUTLOOK.COM>
@ 2023-03-10  0:51 ` Alejandro Colomar
  0 siblings, 0 replies; 3+ messages in thread
From: Alejandro Colomar @ 2023-03-10  0:51 UTC (permalink / raw)
  To: Pascal Cuoq, mtk.manpages
  Cc: linux-man, Guillaume Cluzel, GNU C Library, Andreas Schwab


[-- Attachment #1.1: Type: text/plain, Size: 2190 bytes --]

Hello Pascal,

On 3/8/23 19:10, Pascal Cuoq wrote:
> Hello,
> 
> in 2008 Michael Kerrisk reported that Glibc's nextafter implementation did not set errno as it should:
> 
> https://sourceware.org/bugzilla/show_bug.cgi?id=6799
> 
> That bug was marked as “RESOLVED FIXED” in 2020 but there still exists a disagreement between what the current man page for nextafter at https://man7.org/linux/man-pages/man3/nextafter.3.html says, namely:
> 
>        If x is not equal to y, and the correct function result would be
>        subnormal, zero, or underflow, a range error occurs, and either
>        the correct value (if it can be represented), or 0.0, is
>        returned.
>        …
>        Range error: result is subnormal or underflows
>               errno is set to ERANGE.  An underflow floating-point
>               exception (FE_UNDERFLOW) is raised.
> 
> … and what Glibc's implementation does for nextafter(0., 1.).
> 
> This has been reported by myself in January of 2023:
> 
> https://sourceware.org/bugzilla/show_bug.cgi?id=30040
> 
> As of this writing, the Glibc maintainers' stance appears to be that this behavior is intentional because the specification that Glibc intends to implement only mandates setting errno when the result is zero, and apparently allows setting it or not when the result is 0x1.0p-1074, depending on whether this value was obtained by going one step up from 0.0 or one step down from 0x2.0p-1074.
> 
> If the Glibc maintainers do not consider the current behavior a bug, then this should be noted somehow in the nextafter man page.

Would you please send a patch for the manual page?  You can
find the guidelines for that here:
<https://git.kernel.org/pub/scm/docs/man-pages/man-pages.git/tree/CONTRIBUTING>.

You can clone the git repository from here:
<https://git.kernel.org/pub/scm/docs/man-pages/man-pages.git/>

If you send a patch, please CC the folowing:
Cc: Andreas Schwab <schwab@linux-m68k.org>
Cc: <libc-alpha@sourceware.org>

Thanks,

Alex

> 
> Regards,
> 
> Pascal
> 

-- 
<http://www.alejandro-colomar.es/>
GPG key fingerprint: A9348594CE31283A826FBDD8D57633D441E25BB5

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: nextafter underflow and errno in Glibc
  2023-03-10  7:34 Pascal Cuoq
@ 2023-03-10  8:31 ` Xi Ruoyao
  0 siblings, 0 replies; 3+ messages in thread
From: Xi Ruoyao @ 2023-03-10  8:31 UTC (permalink / raw)
  To: Pascal Cuoq, Alejandro Colomar, mtk.manpages
  Cc: linux-man, Guillaume Cluzel, GNU C Library, Andreas Schwab

On Fri, 2023-03-10 at 07:34 +0000, Pascal Cuoq via Libc-alpha wrote:
> Hello,
> 
> I do not feel confident sending a patch for the following reason:
> 
> Glibc commit 85422c2acba83852396c9d9fd22ff0493e3606fe does contain a
> partial description of the specification that Glibc strives to
> implement:
> 
>     This patch makes them do so in cases that should include all the cases
>     where such errno setting is required by glibc's goals for when to set
>     errno (but not all cases of underflow where the result is nonzero and
>     so glibc's goals do not require errno setting).
> 
> However much remains unclear (for me!) about the specification that
> Glibc strives to implement. Does this mean that the specification is
> actually non-deterministic and that the manpage should contain a
> sentence saying “when the result of nextafter applied to distinct
> arguments x and y is subnormal, nextafter reserves the right to set
> errno to ERANGE but offers not guarantees of doing so; if the result
> is zero, errno is guaranteed to be set to ERANGE”?

> This does not make sense to me: how does one choose one's own
> specification for nextafter, over which one has full control, for a
> basic function that does not need to allocate resources, and make this
> specification non-deterministic? Does the non-determinism apply to the
> floating-point underflow exception as well?

The C17 standard says:

The result underflows if the magnitude of the mathematical result is so
small that the mathematical result cannot be represented, without
extraordinary roundoff error, in an object of the specified type. If the
result underflows, the function returns an implementation-defined value
whose magnitude is no greater than the smallest normalized positive
number in the specified type; if the integer expression math_errhandling
& MATH_ERRNO is nonzero, whether errno acquires the value ERANGE is
implementation-defined; if the integer expression math_errhandling &
MATH_ERREXCEPT is nonzero, whether the "underflow" floating-point
exception is raised is implementation-defined.

"Implementation-defined" means the implementation (Glibc here) has the
freedom to decide what to do, but it has to be documented.  It's
documented in Glibc manual section 20.5.4:

When underflow occurs, the underflow exception is raised, and zero
(appropriately signed) or a subnormal value, as appropriate for the
mathematical result of the function and the rounding mode, is returned.
‘errno’ may be set to ‘ERANGE’, but this is not guaranteed; it is
intended that the GNU C Library should set it when the underflow is to
an appropriately signed zero, but not necessarily for other underflows.

> But then again, I notice that the current manpage description is
> already non-deterministic: a result that should be subnormal can be
> 0.0, confirming that I do not understand Glibc's goals. In these
> conditions I could not do a good job describing the specification that
> Glibc implements.

Just copy from Glibc manual.  But IMO man-page is not a Glibc manual (if
you need Glibc manual you can just read Glibc manual), so a vague "may"
clause like "the errno MAY be set to ERANGE" should be enough (and it's
always true regardless which libc implementation is used). 

-- 
Xi Ruoyao <xry111@xry111.site>
School of Aerospace Science and Technology, Xidian University

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: nextafter underflow and errno in Glibc
@ 2023-03-10  7:34 Pascal Cuoq
  2023-03-10  8:31 ` Xi Ruoyao
  0 siblings, 1 reply; 3+ messages in thread
From: Pascal Cuoq @ 2023-03-10  7:34 UTC (permalink / raw)
  To: Alejandro Colomar, mtk.manpages
  Cc: linux-man, Guillaume Cluzel, GNU C Library, Andreas Schwab

[-- Attachment #1: Type: text/plain, Size: 4021 bytes --]

Hello,

I do not feel confident sending a patch for the following reason:

Glibc commit 85422c2acba83852396c9d9fd22ff0493e3606fe does contain a partial description of the specification that Glibc strives to implement:

    This patch makes them do so in cases that should include all the cases
    where such errno setting is required by glibc's goals for when to set
    errno (but not all cases of underflow where the result is nonzero and
    so glibc's goals do not require errno setting).

However much remains unclear (for me!) about the specification that Glibc strives to implement. Does this mean that the specification is actually non-deterministic and that the manpage should contain a sentence saying “when the result of nextafter applied to distinct arguments x and y is subnormal, nextafter reserves the right to set errno to ERANGE but offers not guarantees of doing so; if the result is zero, errno is guaranteed to be set to ERANGE”? This does not make sense to me: how does one choose one's own specification for nextafter, over which one has full control, for a basic function that does not need to allocate resources, and make this specification non-deterministic? Does the non-determinism apply to the floating-point underflow exception as well?

But then again, I notice that the current manpage description is already non-deterministic: a result that should be subnormal can be 0.0, confirming that I do not understand Glibc's goals. In these conditions I could not do a good job describing the specification that Glibc implements.

Pascal

________________________________
From: Alejandro Colomar
Sent: Friday, March 10, 2023 01:51
To: Pascal Cuoq; mtk.manpages@gmail.com
Cc: linux-man@vger.kernel.org; Guillaume Cluzel; GNU C Library; Andreas Schwab
Subject: Re: nextafter underflow and errno in Glibc

Hello Pascal,

On 3/8/23 19:10, Pascal Cuoq wrote:
> Hello,
>
> in 2008 Michael Kerrisk reported that Glibc's nextafter implementation did not set errno as it should:
>
> https://sourceware.org/bugzilla/show_bug.cgi?id=6799
>
> That bug was marked as “RESOLVED FIXED” in 2020 but there still exists a disagreement between what the current man page for nextafter at https://man7.org/linux/man-pages/man3/nextafter.3.html says, namely:
>
>        If x is not equal to y, and the correct function result would be
>        subnormal, zero, or underflow, a range error occurs, and either
>        the correct value (if it can be represented), or 0.0, is
>        returned.
>        …
>        Range error: result is subnormal or underflows
>               errno is set to ERANGE.  An underflow floating-point
>               exception (FE_UNDERFLOW) is raised.
>
> … and what Glibc's implementation does for nextafter(0., 1.).
>
> This has been reported by myself in January of 2023:
>
> https://sourceware.org/bugzilla/show_bug.cgi?id=30040
>
> As of this writing, the Glibc maintainers' stance appears to be that this behavior is intentional because the specification that Glibc intends to implement only mandates setting errno when the result is zero, and apparently allows setting it or not when the result is 0x1.0p-1074, depending on whether this value was obtained by going one step up from 0.0 or one step down from 0x2.0p-1074.
>
> If the Glibc maintainers do not consider the current behavior a bug, then this should be noted somehow in the nextafter man page.

Would you please send a patch for the manual page?  You can
find the guidelines for that here:
<https://git.kernel.org/pub/scm/docs/man-pages/man-pages.git/tree/CONTRIBUTING>.

You can clone the git repository from here:
<https://git.kernel.org/pub/scm/docs/man-pages/man-pages.git/>

If you send a patch, please CC the folowing:
Cc: Andreas Schwab <schwab@linux-m68k.org>
Cc: <libc-alpha@sourceware.org>

Thanks,

Alex

>
> Regards,
>
> Pascal
>

--
<http://www.alejandro-colomar.es/>
GPG key fingerprint: A9348594CE31283A826FBDD8D57633D441E25BB5

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2023-03-10  8:31 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <PR0P264MB07942F010016373449ED98D6C0B49@PR0P264MB0794.FRAP264.PROD.OUTLOOK.COM>
2023-03-10  0:51 ` nextafter underflow and errno in Glibc Alejandro Colomar
2023-03-10  7:34 Pascal Cuoq
2023-03-10  8:31 ` Xi Ruoyao

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).