Comment 40 for bug 1538361

As I said before, sprintf() is supposed to accept %lf to format a double. And it does, except in inkscape, which means that the %lf is not the root of the problem.

Unfortunately this appears to be a bug in the Windows build method which causes either sprintf() or the trig functions cos(), sin() to be silently replaced at the link stage.

Using this test program:

#include <stdlib.h>
#include <stdio.h>
#include <math.h>
int main(void){
  char huge[64000];
  double esc=0;
  printf("esc %lf cos %lf sin %lf -sin %lf -cos %lf\n",
    esc,cos(esc),sin(esc),-sin(esc),-cos(esc));
  sprintf(huge,"esc %lf cos %lf sin %lf -sin %lf -cos %lf\n",
    esc,cos(esc),sin(esc),-sin(esc),-cos(esc));
  printf("%s\n",huge);
  exit(EXIT_SUCCESS);
}

compile either on linux or Windows (mingw) with

gcc -o printf_bug printf_bug.c -lm

and they both emit (as they should)

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

However, if instead on Windows one links it like one links inkscape, like so:

gcc -c bug_printf.o printf_bug.c
mingw32-g++ -o printf_bug -mconsole -mthreads printf_bug.o -Lc:\progs\devlibs61/ -Lc:\progs\devlibs61/lib -lMagick++ -lMagickCore -laspell -latk-1.0 -latkmm-1.6 -lcairo -lcairomm-1.0 -lcdr-0.1 -lcomdlg32 -lexif -lfontconfig -lfreetype -lgc -lgdi32 -lgdk-win32-2.0 -lgdk_pixbuf-2.0 -lgdkmm-2.4 -lgio-2.0 -lgiomm-2.4 -lglib-2.0 -lglibmm-2.4 -lgobject-2.0 -lgomp -lgsl -lgslcblas -lgthread-2.0 -lgtk-win32-2.0 -lgtkmm-2.4 -liconv -lintl -ljpeg -llcms2 -lm -lmscms -lpango-1.0 -lpangocairo-1.0 -lpangoft2-1.0 -lpangomm-1.4 -lpangowin32-1.0 -lpng -lpoppler -lpoppler-glib -lpopt -lpotrace -lpthreadGC2 -lrevenge-0.0 -lrevenge-stream-0.0 -lsigc-2.0 -ltiff -lvisio-0.1 -lwpd-0.9 -lwpd-stream-0.9 -lwpg-0.2 -lws2_32 -lz c:\progs\devlibs61/bin/libexslt.dll c:\progs\devlibs61/bin/libxml2.dll c:\progs\devlibs61/bin/libxslt.dll

then the output becomes:

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

It doesn't fail in quite the same way as within the program, but that probably just indicates whatever happens
to be nearby in memory is different in the two situations.

Going to

mingw32-g++ -o printf_bug printf_bug.o -lm

produces a binary which works properly.

So apparently one of those libraries, or perhaps a combination of them, is doing something bad. I will try to narrow it down.