[poppler] [PATCH] Fix GDir's handling of return values from FindFirstFile

Patrick Spendrin ps_ml at gmx.de
Wed Apr 2 17:35:18 PDT 2008

Adam Batkin schrieb:
> Hi,
> I believe that there is a small bug in GDir's Windows implementation, if 
> called on a directory that does not exist and you then try to enumerate 
> its entries (getNextEntry()).
> Basically GDir was storing the return value of its call to 
> FindFirstFile() in GDir::hnd, but using NULL as a sentinel for invalid 
> values, but in fact FindFirstFile() returns INVALID_HANDLE_VALUE (-1).
> This patch replaces assignments to NULL with assignments to 
> INVALID_HANDLE_VALUE and all checks now check against 
> So if you are ever using poppler on Windows and your app suddenly 
> crashes (which I was only able to do by compiling with all the debugging 
> options turned on, otherwise I only got funny entries in my log like 
> "Error: Couldn't open 'nameToUnicode' file 
> 'D:\kde-mingw\share\poppler\nameToUnicode\{„žYø!'") this may be why.
> You know what would also be nice...(would you be open to a patch?) not 
> hardcoding POPPLER_DATADIR, since especially on Windows you never know 
> where it will be installed.
> I hope this helps (and I hope I did everything properly...),
Can you please provide a better way to see this problem?
Where did you got the binary from (KDE binary package?)?
So far the patch looks ok, the POPPLER_DATADIR is a more or less serious 
bug since we cannot really assume a fixed directory for the data.
> -Adam Batkin
> ------------------------------------------------------------------------
> _______________________________________________
> poppler mailing list
> poppler at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/poppler

web:                 http://windows.kde.org
mailing list:        kde-windows at kde.org
irc:                 #kde-windows (irc.freenode.net)

More information about the poppler mailing list