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

[William Bader]

> To: poppler at lists.freedesktop.org
> Date: Fri, 4 Mar 2016 13:58:54 -0800
> From: mathog at caltech.edu
> Subject: Re: [poppler] Poppler provided printf() functions on Windows not	language compliant
> 
> On 04-Mar-2016 13:49, mathog wrote:
> > 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
> 
> Hmm, or not.  Downloaded and unpacked poppler-0.41.0 and found that
> 
> grep -R sprintf .
> 
> did not turn up any code that defines a new function.  So now I'm really 
> mystified.
> How would linking in a static libpoppler break an applications' use of a 
> printf() function if it doesn't define a new one?
> 
> Thanks,
> 
> David Mathog
> mathog at caltech.edu
> Manager, Sequence Analysis Facility, Biology Division, Caltech


Do you have any tools to track down bad memory accesses similar to valgrind on Linux?
Maybe a bug somewhere else is trashing a stdio data structure.
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.
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.
Regards, William

 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/poppler/attachments/20160304/7656799e/attachment.html>