Web lists-archives.com

Re: [Mingw-users] bizarre problem, need help from a mingw developer

On 07-Mar-2016 11:48, Keith Marshall wrote:
> On 07/03/16 01:27, mathog wrote:
>> What happens is that a code snippet
>> like this:
>>     double val=1.0;
>>     printf("%lf\n",val);
>> emits 0.0 instead of 1.0.
> One might ask what the author of that code hopes to achieve, with 
> printf
> format specs such as "%lf".  ISO-C says that the "l" modifier is
> redundant (i.e. has no effect) in this context, but Microsoft uses it 
> as
> an alias for the "L" modifier.  Frankly, when you use non-standard
> constructs, such as this, you really are just asking for trouble.

This is getting closer to what I expected - some C library or compiler 
which isn't doing the expected thing with the "%lf". (For some reason.)  
It was very strange that linking in a library would cause it to flip 
behavior though.  Anyway, your post gave me the idea to test the various 
language standards in the compiler, and it turns out that


works properly but


are broken for "%lf" in a printf() statement, and this is WITHOUT adding 

That is:

#this gives the wrong results
gcc -std=c99 -o printf_bug printf_bug.c -lm
val 0.000000
esc 0.000000 cos 0.000000 sin 0.000000 -sin 0.000000 -cos 0.000000
esc 0.000000 cos 0.000000 sin 0.000000 -sin 0.000000 -cos 0.000000

#this gives the right results
gcc -std=gnu89 -o printf_bug printf_bug.c -lm
val 1.000000
esc 0.000000 cos 1.000000 sin 0.000000 -sin 0.000000 -cos 1.000000
esc 0.000000 cos 1.000000 sin 0.000000 -sin 0.000000 -cos 1.000000

On linux both of the compilations noted above give the right results.

The first one seems to be in violation of the C99 language 
section subsection 7 where it says:

l (ell) Specifies that (...) has no effect on a following a, A, e, E, f, 
F, g, or G conversion specifier.

> That said, there is a possible conflict of interests between MinGW's
> interpretation of "%Lf", depending on whether the printf() in use is
> linked from MSVCRT.DLL, (in which both double and long double are
> interpreted as identical 64-bit entities), or the MinGW variant in
> libmingwex.a, (in which double is the same as the MSVCRT.DLL version,
> but long double is GCC's 80-bit representation).  The choice of which
> printf() implementation is linked is determined by feature test macros,
> (look in <_mingw.h> to see which), or by use of -ansi or -posix command
> line options, when invoking gcc/g++.

What happens if the compiler is invoked with -ffloat-store?

Is it possible the mingw feature test macros are used in the poppler 
library, and when these are linked to the simple program (compiled with 
-std=gnu89, so it would work otherwise) causes the linker to select the 
"wrong" printf()? I am still trying to understand how linking in a 
library _where no function is ever called_ can change the behavior of 
the test program.

>> (Within inkscape the bug is much worse, it looks like it is
>> formatting random locations in memory, and extremely long strings of
>> random digits can be returned.)
> This is typical of the behaviour which would be expected, when you push
> a GCC 80-bit long double into the argument list, where printf() expects
> a 64-bit double, (or a 64-bit double, where MinGW's printf() expects an
> 80-bit long double, as will always be the case with "%lf", in MinGW's
> current printf() implementation; that will change in the next release,
> where the ISO-C redundancy effect will be honoured, unless your code
> specifically requests otherwise).

Is the "ISO-C redundancy effect" another name for the behavior described 
above in section of the C99 standard?

Thank you,

David Mathog
Manager, Sequence Analysis Facility, Biology Division, Caltech

Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
MinGW-users mailing list

This list observes the Etiquette found at 
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

You may change your MinGW Account Options or unsubscribe at:
Also: mailto:mingw-users-request@xxxxxxxxxxxxxxxxxxxxx?subject=unsubscribe