In tracking down a bug in Inkscape here:
https://bugs.launchpad.net/inkscape/+bug/1538361
it was discovered that the version of Poppler in devlibs61 appears to
provide its own printf() functions, which replace the usual ones, and
that these mishandle this case:
double val=0.0;
printf("%lf\n",val);
The C and C++ language standards say that the addition of "l" to "%f"
should act the
same as "%f". It does not. The details that matter for Poppler start at
post 40,
including test cases. Note that the phenotype of the failure within
inkscape is a lot more dramatic than in the small test case. Within
Inkscape one of the terms expands to a string of numbers several hundred
characters long. That overflows the buffer and it is all downhill from
there. However, in the test program instead it only just returns "0.0"
where a "1.0" should have been.
This is only a problem on Windows (only 32 bit tested), on Linux (Ubuntu
14.04, 32 bit) the test program works OK, as does Inkscape. Note that
all that is needed to break the test program on windows is to link in
libpoppler. Leave that term off the linker line and it works fine.
So questions:
1. Is it intentional that Poppler override the libc printf() functions,
or is that some glitch in the way the Windows library was constructed?
2. Assuming this is intentional, why does "%lf" fail? Has it been
repurposed, or is this just a bug?
Thank you,
David Mathog
[email protected]
Manager, Sequence Analysis Facility, Biology Division, Caltech
_______________________________________________
poppler mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/poppler
