I haven't used VMS for about two decades, but I remember that the extra options to fopen() are important. Without them, I think that you end up with a record oriented file instead of a stream file, and stdio might not work as you expect, for example, writing '\n' might close the current record instead of writing a 0x0A byte. The full list of parameters is in the entry for creat() at http://h41379.www4.hpe.com/commercial/c/docs/5763p021.html#index_x_600
HP sold VMS to a company that is porting it to Intel x86-64, so VMS might soon be easier to run. http://www.openvms.org/node/107 Regards, William ________________________________ From: poppler <[email protected]> on behalf of Martin (gzlist) <[email protected]> Sent: Sunday, June 24, 2018 8:05 AM To: [email protected] Subject: Re: [poppler] Utils - Fix UTF-16 file name on Windows environment 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 poppler Info Page - freedesktop.org<https://lists.freedesktop.org/mailman/listinfo/poppler> lists.freedesktop.org Subscribing to poppler: Subscribe to poppler by filling out the following form. Use of all freedesktop.org lists is subject to our Code of Conduct.
_______________________________________________ poppler mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/poppler
