Fwd: [PATCH] Files: fix a path encoding issue on Windows

Lubomir I. Ivanov neolit123 at gmail.com
Tue Dec 17 05:11:52 UTC 2013


resent to the mailing list...


---------- Forwarded message ----------
From: Lubomir I. Ivanov <neolit123 at gmail.com>
Date: 17 December 2013 15:11
Subject: Re: [PATCH] Files: fix a path encoding issue on Windows
To: "Lubomir I. Ivanov" <neolit123 at gmail.com>
Cc: Thiago Macieira <thiago at macieira.org>


On 17 December 2013 15:05, Lubomir I. Ivanov <neolit123 at gmail.com> wrote:
> From: "Lubomir I. Ivanov" <neolit123 at gmail.com>
>
> The Qt frontend currently uses a C backend e.g. file.c,
> but Windows does things it's own way and we cannot quite
> relly on methods such as open() to work for paths with
> special characters.
>
> A solution for that is to always pass UTF-8 encoded filenames
> (that may eventually reach file.c:readfile()) and then
> if on Windows converted such to UTF-16 for use with
> the Windows's specific function _wopen().
>
> This possibly avoids re-writing file.c to use Qt/QFile.
>

from the UTF-8 thread:

On 17 December 2013 03:25, Thiago Macieira <thiago at macieira.org> wrote:
> Oh, we should also avoid 8-bit filenames as much as possible, Windows locales
> are not Unicode-complete. Testcase: create C:\Temp\éΓЯ€\ and move one of the
> data files there. Then try to open it.
>
> That would mean rewriting much of file.c to use QFile. At the very least the
> read_file function, with filenames passed as an opaque type through C code.
>

does the above patch solve our win32 issue, thiago?

and isn't fileNamePtr = fileNames.at(i).toUtf8();
the preferred way to do handle this compared to toLocal8Bit()?

also, i know it adds #ifdef WIN32 in file.c which potentially can be
abstracted for clarity in windows.c, linux.c, etc...if requested.

lubomir
--


More information about the subsurface mailing list