From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.linux.lib.musl.general/22188 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Paul Zimmermann Newsgroups: gmane.linux.lib.musl.general Subject: Re: sqrt does not emit errno=EDOM Date: Fri, 04 Jul 2025 11:00:26 +0200 Message-ID: References: <20250703200516.GK1827@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="26934"; mail-complaints-to="usenet@ciao.gmane.io" Cc: musl@lists.openwall.com, maxence.ponsardin@inria.fr To: Rich Felker Original-X-From: musl-return-22208-gllmg-musl=m.gmane-mx.org@lists.openwall.com Fri Jul 04 11:00:47 2025 Return-path: Envelope-to: gllmg-musl@m.gmane-mx.org Original-Received: from second.openwall.net ([193.110.157.125]) by ciao.gmane.io with smtp (Exim 4.92) (envelope-from ) id 1uXcHn-0006s6-JU for gllmg-musl@m.gmane-mx.org; Fri, 04 Jul 2025 11:00:47 +0200 Original-Received: (qmail 1579 invoked by uid 550); 4 Jul 2025 09:00:36 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: x-ms-reactions: disallow Original-Received: (qmail 1531 invoked from network); 4 Jul 2025 09:00:36 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=inria.fr; s=dc; h=date:message-id:from:to:cc:in-reply-to:subject: references; bh=zWda0A6SzS+i1WlZXD2xoguzjhVfhWuzExh8Jo3ukEM=; b=dP07hPqMBnaKGqxzGQxn4dvluhV1/PHDhfwSDVEfFx/wRzmuMO7jLh0D kJ4vbf6JjYrkBOO9LTzp+c/GQnbSoniZwj4Ooz/WDKC1rXJjvcvq7ckog x71StGAERLXghzBYVI/cYcgUoSOK27R3TmAeX47iqKkxgJwmiZMq0fRGs w=; Authentication-Results: mail3-relais-sop.national.inria.fr; dkim=none (message not signed) header.i=none; spf=SoftFail smtp.mailfrom=Paul.Zimmermann@inria.fr; spf=None smtp.helo=postmaster@biscotte Received-SPF: SoftFail (mail3-relais-sop.national.inria.fr: domain of Paul.Zimmermann@inria.fr is inclined to not designate 152.81.4.127 as permitted sender) identity=mailfrom; client-ip=152.81.4.127; receiver=mail3-relais-sop.national.inria.fr; envelope-from="Paul.Zimmermann@inria.fr"; x-sender="Paul.Zimmermann@inria.fr"; x-conformance=spf_only; x-record-type="v=spf1"; x-record-text="v=spf1 include:mailout.safebrands.com a:basic-mail.safebrands.com a:basic-mail01.safebrands.com a:basic-mail02.safebrands.com ip4:128.93.142.0/24 ip4:192.134.164.0/24 ip4:128.93.162.160 ip4:128.93.162.3 ip4:128.93.162.88 ip4:89.107.174.7 mx ~all" Received-SPF: None (mail3-relais-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@biscotte) identity=helo; client-ip=152.81.4.127; receiver=mail3-relais-sop.national.inria.fr; envelope-from="Paul.Zimmermann@inria.fr"; x-sender="postmaster@biscotte"; x-conformance=spf_only X-IronPort-AV: E=Sophos;i="6.16,286,1744063200"; d="scan'208";a="120679038" In-Reply-To: <20250703200516.GK1827@brightrain.aerifal.cx> (message from Rich Felker on Thu, 3 Jul 2025 16:05:17 -0400) Xref: news.gmane.io gmane.linux.lib.musl.general:22188 Archived-At: 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 > 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 > > #include > > #include > > > > 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 >