Re: sqrt does not emit errno=EDOM

[Paul Zimmermann <Paul.Zimmermann@inria.fr>]

thank you Rich for clarifying the Musl position with respect to errno.

Paul

> Date: Thu, 3 Jul 2025 16:05:17 -0400
> From: Rich Felker <dalias@libc.org>
> Cc: musl@lists.openwall.com, maxence.ponsardin@inria.fr
> 
> 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
>