|
Date: Fri, 4 Apr 2014 13:42:30 -0400 From: Morten Welinder <mwelinder@...il.com> To: musl@...ts.openwall.com Subject: Re: printf issues > 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 <dalias@...ifal.cx> 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
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.