|
Date: Fri, 4 Apr 2014 10:12:59 -0400 From: Rich Felker <dalias@...ifal.cx> To: musl@...ts.openwall.com Subject: Re: printf issues 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
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.