Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250703200516.GK1827@brightrain.aerifal.cx>
Date: Thu, 3 Jul 2025 16:05:17 -0400
From: Rich Felker <dalias@...c.org>
To: Paul Zimmermann <Paul.Zimmermann@...ia.fr>
Cc: musl@...ts.openwall.com, maxence.ponsardin@...ia.fr
Subject: Re: sqrt does not emit errno=EDOM

On Thu, Jul 03, 2025 at 09:44:12AM +0200, Paul Zimmermann wrote:
>        Hi,
> 
> it seems musl does not set errno=EDOM for sqrt(x) when x is negative.
> Here on cfarm27 (Alpine Linux):
> 
> $ cat /tmp/e.c
> #include <stdio.h>
> #include <math.h>
> #include <errno.h>
>  
> int
> main()
> {
>   errno = 0;
>   float x = -1.0f;
>   float y = sqrtf (x);
>   printf ("y=%a errno=%d\n", y, errno);
> }
> 
> $ gcc /tmp/e.c -lm
> $ ./a.out 
> y=-nan errno=0
> 
> Is this a known issue?

It's intentional that none of musl's math library sets errno.
Implementations have the option to do either or both of setting errno
or raising fenv exception flags as long as this is reflected in the
value of math_errhandling.

Generally, the modern view seems to be that setting errno is bad
practice. It makes it so that the math functions can never be treated
as pure functions by the compiler (note: fenv also breaks purity but
the application gets to signal whether it wants FENV_ACCESS or not,
and if not, they're pure).

Note that on soft float archs without fenv, omitting errno is actually
nonconforming. It was originally my hope that we'd eventually get soft
fenv working on these, but they seem to be of waning relevance these
days anyway. I don't see adding errno as an appropriate fix for this.
Applications generally don't want it, and any such effort to add it
would be better spent on workout out a way to do soft fenv.

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.