Handle non-ASCII filenames correctly on Windows #91
Conversation
Fix snoyberg#90. Idea: reuse low-level API from GHC internals, since it has already tested low-level code to deal with non-ASCII filenames on different platforms.
A null file pointer doesn't need closing; `fclose_helper` will indeed do nothing on a null pointer.
I've ensured both parts of the test fail without the changes. To ensure the whole test fails without the fixes, accented characters must be in the path argument, not just in the current working directory.
Blaisorblade
force-pushed
the
90-safe-intl-filename
branch
from
29825c4
to
5c2b6b2
Compare
|
This PR is now ready for review, though on Windows I only tested on GHC 7.10.3 (with LTS-3 with relaxed version checks and LTS-6). |
| -- indicated via both 'rawOpenFlags' and 'openMode'. | ||
| openFile :: FilePath -> CInt -> String -> IO File | ||
| openFile file rawOpenFlags openMode = do | ||
| fd <- liftIO $ Posix.withFilePath file $ \file' -> |
There was a problem hiding this comment.
I'm surprised that such a large change is needed. Is it insufficient to simply replace withCString with Posix.withFilePath and leave the rest of the code the same as it was before?
There was a problem hiding this comment.
IIRC from two weeks ago, the first problem is that fopen doesn't do the right thing on Windows, because it takes normal characters instead of wide ones. This might be wrong, but I remember solving this by hand looked non trivial.
Instead, this code simply reuses the existing tested solution in GHC's libraries, which happens to provide a variant of open instead of fopen. To wit, as soon as this worked on Mac, it worked on Windows.
I look into it again if you want for more accurate details, but not tonight.
Also, sorry for the delay in replying, forgot y this email.
|
Sorry for the delay here, vacation definitely intervened. I'm going to start by setting up appveyor so we can get some Windows testing going on this. |
|
OK, I can confirm that due to wide characters the simple approach I mentioned does not work. |
|
I'll release to Hackage once the AppVeyor and Travis builds succeed. |
|
I'm honestly blown away that you seem to have been the first person to On Mon, Sep 5, 2016 at 10:46 PM Paolo G. Giarrusso notifications@github.com
|
This has been fixed upstream, see: snoyberg/yaml#91
This has been fixed upstream, see: snoyberg/yaml#91
Not yet finished, but I've confirmed this code fixes the bug on Windows. EDIT: at least with GHC 7.10.3. I'll add a test and rebase.