From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_MSPIKE_H2,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 30092 invoked from network); 30 Aug 2022 12:26:45 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 30 Aug 2022 12:26:45 -0000 Received: (qmail 1894 invoked by uid 550); 30 Aug 2022 12:26:42 -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 1862 invoked from network); 30 Aug 2022 12:26:41 -0000 Date: Tue, 30 Aug 2022 08:26:28 -0400 From: Rich Felker To: ardi Cc: musl@lists.openwall.com Message-ID: <20220830122627.GA16467@brightrain.aerifal.cx> References: <20220819031934.GH7074@brightrain.aerifal.cx> <20220823173020.GJ7074@brightrain.aerifal.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] Do you recommend using fmt_fp() and On Tue, Aug 30, 2022 at 12:17:50PM +0200, ardi wrote: > On Tue, Aug 23, 2022 at 7:30 PM Rich Felker wrote: > > > > See how strtod.c uses sh_fromstring and how sh_fromstring does not > > define any io callbacks (so that calling __uflow would necessarily > > result in a call to a null or ununitialized function pointer). From > > that, it's clear that it must not be reachable (or the existing code > > in musl would be broken). > > Thanks a lot. Understood. While in the process of adapting the code, > I came across the implementation of scalbnl(), and I'm not sure if > I found a mistake or if it's correct: lines 23 to 27 of src/math/scalbnl.c > use MANT_DIG but hardcode it as 113 both when long double is > binary128 and when it's 80bit extended (where MANT_DIG is 64). > > By comparison, looking at the source of the scalbn() versions for > float and double, I'd say there's a mistake in the long double version, > but I've never written that function myself, so I'm not in a position > to affirm it for sure. > > Kind regards, and thanks a lot, I think the scaling just needs to be large enough to ensure we get out of the subnormal range but not so large as to overflow. Since it's conditioned on starting out with a negative exponent in the subnormal range, you'd need an exponent much larger than the max positive exponent for scaling to overflow, so 113 is safe and the only point of the number being 113 is that it's sufficient for both formats. That's just my quick reading of what's going on, so if anyone thinks I'm wrong about it, please speak up. Rich