On 19/06/2018, Albert Astals Cid <[email protected]> wrote: > > It does make some sense given that function exists in the first place but my > experience with windows is veeeeeeeeeeeeery limited so I'd like for someone > else to vouch for this before landing it.
Overall the change might be, but there are some tricky aspects. On windows fopen takes a narrow string of variable codepage, and openFile takes (sort-of*) utf-8 but the types are not distinguished in the codebase so it's tricky to see what callers are providing. In cases where the string being used comes straight from say, the command line or environment block, it will not be utf-8 so non-ascii characters will be mangled. That's probably best fixed by ensuring on GooString construction that it's converted to utf-8 but at present that's entirely unvalidated. Also: #ifdef VMS - f = fopen(fileName->getCString(), "rb", "ctx=stm"); + f = openFile(fileName->getCString(), "rb", "ctx=stm"); #else - f = fopen(fileName->getCString(), "rb"); + f = openFile(fileName->getCString(), "rb"); #endif Breaks compilation on VMS (if that's still a platform that matters) as openFile takes two args only. Oddly, GooFile::open already includes this logic but openFile does not. Can just drop the first branch change for now. Martin *sort-of utf-8: gfile.cc has a pretty half-assed utf-8 to utf-16 conversion algorithm in several places that only correctly handles a subset of inputs. _______________________________________________ poppler mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/poppler
