Date: Fri, 4 Apr 2014 10:35:00 -0400 From: Morten Welinder <mwelinder@...il.com> To: musl@...ts.openwall.com Subject: Re: printf issues > 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. > 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. Morten On Fri, Apr 4, 2014 at 10:15 AM, Szabolcs Nagy <nsz@...t70.net> wrote: > * Morten Welinder <mwelinder@...il.com> [2014-04-04 09:32:18 -0400]: >> 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. > > before you can mock libc code you need to educate yourself > > LDBL_MANT_DIG is an identifier (macro definition) that is > defined by the libc itself (in arch/$ARCH/bits/float.h), > not by the application, nor by the compiler > > the libc can internally rely on a different contract about > the identifiers it defines, than application code that has > to rely on the external contracts specified by ISO C > > so outside the implementation you shouldn't use such a code > because there is no guarantee how LDBL_MANT_DIG is defined, > but internally the libc knows how it defined its symbols and > thus the code is perfectly reasonable > > (this distinction between public interface contracts and > implementation internal interface contracts is often > misunderstood: so don't copy-paste code between libc and > application code without thinking and don't try to reason > about APIs/ABIs used inside the libc based on the public > specification of those APIs/ABIs)
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.