From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/4779 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: printf issues Date: Fri, 4 Apr 2014 10:12:59 -0400 Message-ID: <20140404141259.GL26358@brightrain.aerifal.cx> References: Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1396620800 1839 80.91.229.3 (4 Apr 2014 14:13:20 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 4 Apr 2014 14:13:20 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-4783-gllmg-musl=m.gmane.org@lists.openwall.com Fri Apr 04 16:13:13 2014 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1WW4rp-0002Xl-8K for gllmg-musl@plane.gmane.org; Fri, 04 Apr 2014 16:13:13 +0200 Original-Received: (qmail 25912 invoked by uid 550); 4 Apr 2014 14:13:12 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 25900 invoked from network); 4 Apr 2014 14:13:12 -0000 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:4779 Archived-At: On Fri, Apr 04, 2014 at 09:32:18AM -0400, Morten Welinder wrote: > I am seeing differences in how printf("%.200Lg",val) works between musl code > and glibc. > > Here are some samples. The top line is how musl prints, the bottom is glibc. > > -65878995336522048.000000000 > -65878995336522048 > > 1954675876964773.500000000 > 1954675876964773.5 > > 3953605802361882.000000000 > 3953605802361882 Confirmed that this bug exists. It seems to be an error in how the trailing zero removal logic works in certain cases, but I didn't figure out the pattern immediately except that it seems to be associated with large-magnitude numbers like yours. I'll run some better tests in a little bit. > Unrelatedly, from function fmt_fp: > > #define CONCAT2(x,y) x ## y > #define CONCAT(x,y) CONCAT2(x,y) > [...] > long double round = CONCAT(0x1p,LDBL_MANT_DIG); > > That code is cute as a Hello Kitty door knocker, but really? Let's hope nobody > gets the urge to define LDBL_MANT_DIG as 0100 or (80-16) or some such. > The first case will still compile, but get the wrong result. Yes, this assumes our headers which define it as an unadorned decimal constant. Do you have any ideas for a clean way to avoid this assumption without having to compute the value at runtime? Rich