Created attachment 89529 [details] the defect PDF The attached PDF forces pdftoppm to run into an endless loop when trying to reconstruct XRef table. Reason for it is the windows version of GooFile::read which returns -1 when trying to read after EOF, but the calling FileStream::fillBuf() doesn't check for -1.
Created attachment 89532 [details] [review] Patch for the problem This patch solves the problem, GooFile::read now returns 0 bytes read and causes FileStream::fillBuf() to detect the EOF.
would it be better to check the return value? Reading the doc of pread (what we use in posix) it can return -1 too it seems, so it'd break too, no? Or maybe also change the GooFile::read to make sure it never returns -1? What do you prefer?
Created attachment 89568 [details] [review] Alternate patch for this problem I would prefer to check for "-1". This was already my first solution, but because this PDF doesn't make problems under Unix, I changed my first solution without examining the Unix solution. But since pread can return "-1" too, I think this patch is the more general solution.
commited!
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.