Summary: | printf() breaks in simple program when libpoppler is linked to it | ||
---|---|---|---|
Product: | poppler | Reporter: | mathog <mathog> |
Component: | general | Assignee: | poppler-bugs <poppler-bugs> |
Status: | RESOLVED INVALID | QA Contact: | |
Severity: | normal | ||
Priority: | medium | ||
Version: | unspecified | ||
Hardware: | x86 (IA32) | ||
OS: | Windows (All) | ||
Whiteboard: | |||
i915 platform: | i915 features: |
Description
mathog
2016-03-05 02:16:31 UTC
What I've been able to tell from compiling the test program and looking at the disassembly, linking with libpopplar will make it use a mingw printf, otherwise it uses a msvcrt printf. It might be because poppler builds with -D__USE_MINGW_ANSI_STDIO=1. Building your test program with that defined will make the same error, even when not linking with poppler. The problem is in mingw. Poppler was almost entirely an innocent bystander. Depending on who knows what variables sometimes the linker gives you a printf() from one library and other times you get the one from MSVCRT.dll. The problem is that the latter one is not strictly compliant with any of the recent C language standards. In particular, in the context of a printf() it considers "%lf" to be a synonym for "%LF". Something in the problematic poppler libraries is throwing that switch, resulting in the observed bugs. For all I know building these libraries slightly differently would eliminate whatever this mysterious something is. It doesn't seem to be a function of the Poppler code per se. I also discovered a really ironic way to get the wrong printf. gcc -std=gnu89 -o printf_bug printf_bug.c ./printf_bug follows the C99 standard for how %lf should work, but gcc -std=c99 -o printf_bug printf_bug.c ./printf_bug does not, it apparently uses the MSVCRT.dll printf(). In other words, specifically requesting a language standard which says what "%lf" should do in this context gives you the opposite result! Note: mingw apparently also has issues with printf() and long doubles. As I understand it one library expects them to be 80 bits and the other 64 bits. Some future version of mingw may resolve these issues, all it has to do is give its printf() precedence over the one in MSVCRT. Sorry Jason, I didn't see your last comment. Yes that is it. No bug then, right? Not in poppler. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.