Created attachment 41235 [details] Use Guint rather than uint in FontInfo.cc While building Poppler using the Visual Studio toolchain I ran into several small issues. Attached are three small patches fixing the issues I encountered. Patch #1: FontConfig.cc uses uint which is not known by the compiler. Patch #2: Qt4 Frontend: The structs defined within the Annotation class are not marked as exported. This causes problem when linking against the produced DLL. Patch #3: MSDN says (http://msdn.microsoft.com/de-de/library/14h5k7ff%28VS.80%29.aspx) that the buffer should be of type struct _stat. Secondly, fileName2 has to be type casted to a wchar_t which should be fine. However, in the else case I am not sure whether _wstat or the _stat version of the command should be used (I am not too familiar with Windows encoding issues between the different releases). All patches were made against 0.15.3 but should apply just fine to todays git version.
Created attachment 41236 [details] [review] Export annotation structs in Qt4 frontend
Created attachment 41237 [details] [review] Fixes type cast issues with Visual Studio compiler
I'm a little confused of why you need - if (_wstat(fileName2, &buf) == 0) { + if (_wstat((const wchar_t *) fileName2, &buf) == 0) { if fileName2 is already a wchar_t array and thus a const wchar_t *
(In reply to comment #3) > I'm a little confused of why you need > - if (_wstat(fileName2, &buf) == 0) { > + if (_wstat((const wchar_t *) fileName2, &buf) == 0) { > if fileName2 is already a wchar_t array and thus a const wchar_t * Ok I must've looked at the wrong line when the compiler notified me about it. I guess the compilation error was caused by the _wstat call in the else branch a couple of lines below.
Patch 1 is there from another bug, i've commited patch 2. I'm a bit concerned patch 3 might break mingw builds though (not sure _stat is available there).
(In reply to comment #5) > Patch 1 is there from another bug, i've commited patch 2. > > I'm a bit concerned patch 3 might break mingw builds though (not sure _stat is > available there). I have just checked with MinGW 4.4.0 available from Nokia (at ftp://ftp.qt.nokia.com/misc/MinGW-gcc440_1.zip) and it does know about _stat (in sys/stat.h). The same also applies to MinGW 3.4.2 also available from the Qt FTP.
Comment on attachment 41237 [details] [review] Fixes type cast issues with Visual Studio compiler What is the reason for changing the use of _wstat() to _stat() in the else statement?
(In reply to comment #7) > (From update of attachment 41237 [details] [review]) > What is the reason for changing the use of _wstat() to _stat() in the else > statement? The else branch seems to be the fallback for non-NT based versions of Windows (e.g. Windows 9x, ...) which do not support wide character strings. I don't know why _wstat was used in this branch as, similarly to _wfopen, it is not available on those systems (see the Requirements section in http://msdn.microsoft.com/en-us/library/14h5k7ff%28v=VS.80%29.aspx).
(In reply to comment #8) > (In reply to comment #7) > > (From update of attachment 41237 [details] [review] [details]) > > What is the reason for changing the use of _wstat() to _stat() in the else > > statement? > > The else branch seems to be the fallback for non-NT based versions of Windows > (e.g. Windows 9x, ...) which do not support wide character strings. I don't > know why _wstat was used in this branch as, similarly to _wfopen, it is not > available on those systems (see the Requirements section in > http://msdn.microsoft.com/en-us/library/14h5k7ff%28v=VS.80%29.aspx). Ah, I see now, thanks. I think the non-NT based branch was never tested recently then. Using _stat instead of _wstat seems fine for me then.
Ok, i've commited all the patches.
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.