Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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.