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

    -std=gnu89

works properly but

    -std=c99
    -ansi

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

That is:

#this gives the wrong results
gcc -std=c99 -o printf_bug printf_bug.c -lm
./printf_bug
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
./printf_bug
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 
specification,
section 7.19.6.1 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 7.19.6.1 of the C99 standard?

Thank you,

David Mathog
mathog@xxxxxxxxxxx
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.
http://makebettercode.com/inteldaal-eval
_______________________________________________
MinGW-users mailing list
MinGW-users@xxxxxxxxxxxxxxxxxxxxx

This list observes the Etiquette found at 
http://www.mingw.org/Mailing_Lists.
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:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:mingw-users-request@xxxxxxxxxxxxxxxxxxxxx?subject=unsubscribe