<html> <head> <style></style></head> <body class='hmmessage'><div dir='ltr'><br><br><div>> To: poppler@lists.freedesktop.org<br>> Date: Fri, 4 Mar 2016 13:58:54 -0800<br>> From: mathog@caltech.edu<br>> Subject: Re: [poppler] Poppler provided printf() functions on Windows not language compliant<br>> <br>> On 04-Mar-2016 13:49, mathog wrote:<br>> > In tracking down a bug in Inkscape here:<br>> > <br>> > https://bugs.launchpad.net/inkscape/+bug/1538361<br>> > <br>> > it was discovered that the version of Poppler in devlibs61 appears to<br>> > provide its own printf() functions, which replace the usual ones<br>> <br>> Hmm, or not. Downloaded and unpacked poppler-0.41.0 and found that<br>> <br>> grep -R sprintf .<br>> <br>> did not turn up any code that defines a new function. So now I'm really <br>> mystified.<br>> How would linking in a static libpoppler break an applications' use of a <br>> printf() function if it doesn't define a new one?<br>> <br>> Thanks,<br>> <br>> David Mathog<br>> mathog@caltech.edu<br>> Manager, Sequence Analysis Facility, Biology Division, Caltech<br></div><div><br></div><div><br></div><div>Do you have any tools to track down bad memory accesses similar to valgrind on Linux?</div><div><br></div><div>Maybe a bug somewhere else is trashing a stdio data structure.</div><div><br></div><div>I did some MSDOS programming in the 80's, and I remember that stdio was one of the first things in memory, so writes to null pointers would sometimes make stdio fail in strange ways.</div><div><br></div><div>Also, if the crash is in sprintf() and not printf(), have you double checked that the receiving buffer is large enough? Maybe the Windows %lf writes a longer string than you expected. Using snprintf() is safer.</div><div><br></div><div>Regards, William</div><div><br></div><div><br></div> </div></body> </html>