From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/4784 Path: news.gmane.org!not-for-mail From: Morten Welinder Newsgroups: gmane.linux.lib.musl.general Subject: Re: printf issues Date: Fri, 4 Apr 2014 13:42:30 -0400 Message-ID: References: <20140404141515.GD3034@port70.net> <20140404150705.GN26358@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 X-Trace: ger.gmane.org 1396633369 1729 80.91.229.3 (4 Apr 2014 17:42:49 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 4 Apr 2014 17:42:49 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-4788-gllmg-musl=m.gmane.org@lists.openwall.com Fri Apr 04 19:42:44 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 1WW88a-0003SP-30 for gllmg-musl@plane.gmane.org; Fri, 04 Apr 2014 19:42:44 +0200 Original-Received: (qmail 31845 invoked by uid 550); 4 Apr 2014 17:42:42 -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 31837 invoked from network); 4 Apr 2014 17:42:42 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=jqXqNu55f1whyaxotGz5IOkF5COtnlCNuv2jyzkU2H8=; b=Y9BWCD7ihpjPOlhteNj6BTDuKsfBumxOoGi++c/75yLa/cL2DzkCiY/bSe9WMzpr9i gOe57m98kBl+25xZLsIXQaPxbYUclXPjwBZ1uFOShFFyysdf3QpfbAqyk35Te/I2SrBQ HRzFXmH/TOBpBuuJYgmlxZjIiUigZ7pzAolM9AaFP1aIPyelZTvkwdzteNkU1yXKo3+a oPWWPMGfN4dNagyF09Xj6Y1HJ7BW8pbG6T7TTr9K+nN30y/XY/va1bOKNSg078+eOQbR sHuQb70i0vb06R0za60pQHgiUFMwyVnl63soABwf9anDObviJpOr4wGdwfKiN0wMsUsO 7Nng== X-Received: by 10.180.85.134 with SMTP id h6mr6441862wiz.44.1396633350967; Fri, 04 Apr 2014 10:42:30 -0700 (PDT) In-Reply-To: <20140404150705.GN26358@brightrain.aerifal.cx> Xref: news.gmane.org gmane.linux.lib.musl.general:4784 Archived-At: > I _would_ like this code to be easily adaptable for use outside libc > if somebody wants it FYI, I have been doing just that for Gnumeric in a variant that always rounds ties away from zero. Two changes would help with making the code fit seamlessly into other environments. 1. Make "i" in fmt_fp unsigned. It's used in connection with unsigned values only. 2. Make "char *s" used to hold "NAN" etc. "const char *s". Neither of these should make any difference in what the function actually does. I have run tens of millions random numbers through this function looking for differences between it and glibc. The extra 0s from "%g" is the only problem observed. It looks like the LDBL_EPSILON version could be used in roundl.c modfl.c ceill.c floorl.c in the definition of TOINT instead of enumerating choices for LDBL_MANT_DIG. It's basically the same thing going on there. While I was looking for that, I noticed that this modfl fallback looks problematic. Even if long double and double are the same thing under the hood, I don't think you can cast pointers like that and assume it works. It needs a temporary. #if LDBL_MANT_DIG == 53 && LDBL_MAX_EXP == 1024 long double modfl(long double x, long double *iptr) { return modf(x, (double *)iptr); } Morten On Fri, Apr 4, 2014 at 11:07 AM, Rich Felker wrote: > On Fri, Apr 04, 2014 at 10:35:00AM -0400, Morten Welinder wrote: >> > before you can mock libc code you need to educate yourself >> >> I did and that's why I called the code "cute", not "wrong". But if you read >> the porting documentation >> >> http://brightrain.aerifal.cx/~niklata/PORTING >> http://www.openwall.com/lists/musl/2012/07/08/1 >> >> you will notice that nowhere does it warn that defining LDBL_MANT_DIG >> as anything but a base-10 constant may cause printf-rounding to fail. > > Good point. > >> > Do you have any ideas for a clean way to avoid this >> > assumption without having to compute the value at runtime? >> >> I don't know if ldexpl will get constant folded by the compiler, but if not, >> I think (2.0L/LDBL_EPSILON) ought to work as a replacement. It's not >> as likely to get prices at the obfuscated C contents, though. > > Thanks, I think that's exactly the right solution. FWIW, I _would_ > like this code to be easily adaptable for use outside libc if somebody > wants it, so eliminating implementation-internal assumptions like this > is nice. > > Rich