On 6 Jun 2026, at 13:42, Carlo B. via Cygwin <[email protected]> wrote: > > Hello, > look this tiny C source code: > > ======== > > #include <stdio.h> > #include <math.h> > > int main() > { > double value = 0x1p1023; > > printf("log2=%.14f\n", log2(value)); > #undef log2 > printf("log2=%.14f\n", log2(value)); > > return 0; > } > > ======== > > Compile it with a simple command: > > $ gcc test_log2.c -o test_log2.exe > > and run it. > The result on the console is: > > log2=1023.00000000000011 > log2=1023.00000000000000 > > If you look inside math.h from newlib, you will see this code: > > extern double log2 (double); > #if !defined(__cplusplus) > #define log2(x) (log (x) / _M_LN2) > #endif > > As you can see, my simple test program just calculates log2() by using > log() function and next, after undefining log2() macro, it uses the > true log2() function. > > Actually, that macro log2() "overloads" the log2() function. > And as result, the calculation of "(log (x) / _M_LN2)" loses the > precision on the last bits of the result. > It is not clear to me if there is a particular reason for doing so, > because this thing makes the Python's test suite to fail on the tests > for the log2() function. > What do you think? > Because log2() function was perfectly able to pass the tests.
It's been defined like that since the "import newlib-2000-02-17 snapshot", so for 26 years: https://sourceware.org/git/?p=newlib-cygwin.git;a=blob;f=newlib/libc/include/math.h;h=d3f2e99ae4d33596b608225f0349a6d581d265ca;hb=8a0efa53e44919bcf5ccb1d3353618a82afdf8bc#l103 My guess is that at the time, there wasn't yet a separate log2() implementation, so this was an easy way to cover that case. -Dimitry -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation: https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
