From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/4791 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 16:58:08 -0400 Message-ID: <20140404205808.GP26358@brightrain.aerifal.cx> 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=us-ascii X-Trace: ger.gmane.org 1396645108 14198 80.91.229.3 (4 Apr 2014 20:58:28 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 4 Apr 2014 20:58:28 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-4795-gllmg-musl=m.gmane.org@lists.openwall.com Fri Apr 04 22:58:22 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 1WWBBt-0001As-JC for gllmg-musl@plane.gmane.org; Fri, 04 Apr 2014 22:58:21 +0200 Original-Received: (qmail 27824 invoked by uid 550); 4 Apr 2014 20:58:20 -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 27803 invoked from network); 4 Apr 2014 20:58:20 -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:4791 Archived-At: On Fri, Apr 04, 2014 at 01:42:30PM -0400, Morten Welinder wrote: > > 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. I don't object, but what's the motivation? > 2. Make "char *s" used to hold "NAN" etc. "const char *s". Indeed, this is harmless. I assume it's to satisfy that ugly option that changes the type of string literals from char[] to const char[]? BTW that option actually just got a lot more problematic with C11; now that C has _Generic, it potentially changes the semantics of a program rather than just helping generate warnings. > 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. Nice. I was actually thinking of some numerical tests we could run on huge random samples, for instance using using theorems about properties of the digits of the decimal expansion (e.g. n%3==0 iff the sum of the digits mod 3==0; this works for diadic-rational 'multiples of 3' too). > 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. Indeed, this would be a welcome change. > 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); > } Agreed. This is UB (an aliasing violation) and should be fixed even if it makes the function a few bytes larger/a few cycles slower. Rich