From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.3 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: from second.openwall.net (second.openwall.net [193.110.157.125]) by inbox.vuxu.org (Postfix) with SMTP id 5AD552898F for ; Mon, 5 Aug 2024 15:18:52 +0200 (CEST) Received: (qmail 30514 invoked by uid 550); 5 Aug 2024 13:18:49 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 30470 invoked from network); 5 Aug 2024 13:18:48 -0000 Date: Mon, 5 Aug 2024 09:18:39 -0400 From: Rich Felker To: Selene Corbineau Cc: musl@lists.openwall.com, Paul Zimmermann Message-ID: <20240805131839.GZ10433@brightrain.aerifal.cx> References: <9ea8df217179a1c6c7bc0bd0d7001721@ens.psl.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9ea8df217179a1c6c7bc0bd0d7001721@ens.psl.eu> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] Obsolete comment in powl, and (s)NaN handling ? On Mon, Aug 05, 2024 at 02:22:34PM +0200, Selene Corbineau wrote: > Hello, > > Currently, src/math/powl.c line 66 states that powl(x, y) > returns 0 when x < 0 and y not an integer. However, lines 290-291 Indeed, that comment seems totally wrong and probably comes from some awful legacy mode that was omitted when importing the code (no fenv or nans, exceptional results via errno). I think that whole paragraph should just be deleted since "error messages" are not a thing in ours or any modern libm. > >if (iyflg == 0) > > return (x - x) / (x - x); /* (x<0)**(non-int) is NaN */ > > precisely ensure this is not the case. Both these excerpts come > from the original commit. Maybe line 66 should be deleted/corrected ? Yes, or as above. > Deviating a bit, are there plans for supporting signalling NaNs in > Musl ? No, and I wouldn't expect there to be unless at some point there were a compelling conformance reason. The tooling all botches a lot of stuff about handling them, and making them work right probably imposes performance cost on the 3+ nines of software that have no interest in them. Rich