[poppler] Poppler provided printf() functions on Windows not language compliant

mathog mathog at caltech.edu
Fri Mar 4 21:49:38 UTC 2016


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
mathog at caltech.edu
Manager, Sequence Analysis Facility, Biology Division, Caltech


More information about the poppler mailing list