public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: Pascal Cuoq <cuoq@trust-in-soft.com>
To: Alejandro Colomar <alx.manpages@gmail.com>,
	"mtk.manpages@gmail.com" <mtk.manpages@gmail.com>
Cc: "linux-man@vger.kernel.org" <linux-man@vger.kernel.org>,
	Guillaume Cluzel <guillaume.cluzel@trust-in-soft.com>,
	GNU C Library <libc-alpha@sourceware.org>,
	Andreas Schwab <schwab@linux-m68k.org>
Subject: Re: nextafter underflow and errno in Glibc
Date: Fri, 10 Mar 2023 07:34:30 +0000	[thread overview]
Message-ID: <PR0P264MB07941B6AF99182D1CE404018C0BA9@PR0P264MB0794.FRAP264.PROD.OUTLOOK.COM> (raw)

[-- 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

             reply	other threads:[~2023-03-10  7:34 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-10  7:34 Pascal Cuoq [this message]
2023-03-10  8:31 ` Xi Ruoyao
     [not found] <PR0P264MB07942F010016373449ED98D6C0B49@PR0P264MB0794.FRAP264.PROD.OUTLOOK.COM>
2023-03-10  0:51 ` Alejandro Colomar

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=PR0P264MB07941B6AF99182D1CE404018C0BA9@PR0P264MB0794.FRAP264.PROD.OUTLOOK.COM \
    --to=cuoq@trust-in-soft.com \
    --cc=alx.manpages@gmail.com \
    --cc=guillaume.cluzel@trust-in-soft.com \
    --cc=libc-alpha@sourceware.org \
    --cc=linux-man@vger.kernel.org \
    --cc=mtk.manpages@gmail.com \
    --cc=schwab@linux-m68k.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).