[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20261013125147.GR23438@brightrain.aerifal.cx>
Date: Tue, 13 Oct 2026 08:51:47 -0400
From: Rich Felker <dalias@...c.org>
To: Kang-Che Sung <explorer09@...il.com>
Cc: musl@...ts.openwall.com, Song-Jiang <songjiang@...gxue.org>
Subject: Re: strtod/strtof: errno not set to ERANGE when result rounds
up to a subnormal power of two
On Tue, Oct 13, 2026 at 07:34:15PM +0800, Kang-Che Sung wrote:
> On Tue, Oct 13, 2026 at 5:11 AM Rich Felker <dalias@...c.org> wrote:
> >
> > On Mon, Oct 12, 2026 at 03:53:14PM +0000, Song-Jiang wrote:
> > > musl's strtod and strtof do not set errno to ERANGE when an inexact
> > > decimal input rounds *up* to a subnormal power of two. The returned
> > > value is correct; only errno is missing. ERANGE is set for every other
> > > underflowing input I tried: subnormal results that are not powers of
> > > two, subnormal powers of two reached by rounding *down* (e.g. "5e-324"),
> > > and inputs just below the smallest normal. Inexact inputs that round up
> > > to the smallest normal itself (e.g. "2.2250738585072014e-308")
> > > correctly stay silent, so this is not the usual FLT_MIN/DBL_MIN case.
> >
> > Attached patch should fix this.
> >
>
> By the way, what's the behavior of `strtod`/`strtof` if the result is
> too small to represent even for a subnormal number and the rounding
> mode forces the functions to round *down* the results to zero?
This is also a case of underflow that needs to be reported. Underflow
happens whenever the rounding causes the result to have fewer
significant bits than the full mantissa width of the type.
One way of thinking of this is that, while the standard classification
of floating point numbers distinguishes denormals from zeros,
functionally a zero is just a denormal with all of the mantissa bits
zero.
> Note: The C standard does not require the result of an underflow to be
> indicated by setting `errno` to `ERANGE`. The C standard says:
> "[W]hether `errno` acquires the value `ERANGE` is implementation-defined".
> So it's okay for a library to not set `errno` to `ERANGE` for the
> underflow cases.
That is the base C standard not POSIX. We aim to comply to POSIX.
> Personally I think using `errno` for catching an underflow is a bad
> idea. First, C has API for retrieving the floating point exception
> flags directly (`fetestexcept` and like). Seconds, sometime an
> underflow error is indistinguishable from the generic `FE_INEXACT`
> error, and the latter does not require setting `errno`. I think for
> the intuitive use for floating points, it's better to not set `errno`
> for any underflow case at all.
>
> Just my opinion.
OK, but this is not a matter of opinion but of the interface contract.
As I understand it, up through C11 (and its revisions through defect
reports) the strtod family is not specified to have any particular
effect on fenv but reports overflow (mandatory) and underflow
(optional) through errno.
The latest version of the C standard, C23, changes this and makes it
follow math_errhandling.
The latest POSIX (2024 edition) is not aligned with C23 (C23 came too
late for it), so POSIX still requires the errno behavior, and makes
reporting underflow mandatory not optional.
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
