| |
| |
On 2/17/21 11:23 AM, Ian MacArthur
wrote:
On 17 Feb 2021, at 00:19, Bill Spitzak wrote:
I believe in Windows 10 they finally fixed UTF-8. You can set the locale so that filenames for open(), etc, are interpreted as UTF-8 strings. I strongly recommend this as the correct fix, and that the wrapper functions be removed.
But does that not leave us having to distinguish between WIn10 and Win-(older) at runtime then do something different...?
There’s still an lot (a majority?) of older systems out there in the wild...
Perhaps the right thing is to make a wrapper fl_open() (we don't
have one presently I don't think)
and have it detect use the UTF8 -> WC conversion only when
needed, so that we can open files
with utf8 strings.
Do we really know if it's an OS thing (Windows 10?) in which
case it'd be a runtime check,
or is it a C library version thing, in which case it'd be
compile time?
One thing seems sure; open() doesn't handle utf8 pathnames on
Windows.
I did a short test with a utf8 encoded subdirectory on my file
server, the open() operation fails
on Windows 8 for both mingw and VS2017, even though the command
line cat/type can show the file just fine.
And of course on Mac and Linux the program works fine; test
program attached as utf8test.cxx.
Results below for the filename "./UTF8-作藩于外/foo/foo.txt"
(hoping that posts OK).
I was able to get _wopen() to work in mingw by
modifying that program to use a wchar_t string,
so it does seem to be an issue with the windows implementation
of open()/_open().
--
You received this message because you are subscribed to the Google Groups "fltk.coredev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fltkcoredev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/fltkcoredev/f54ce362-abb7-e428-2a51-ccd54a1043d1%40seriss.com.
[ Direct Link to Message ] | |
|
| |
