| |
| |
On 2/17/21 10:43 PM Greg Ercolano 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.
Even if it worked for newer systems we couldn't rely on it because FLTK
also supports older Windows versions and, of course, we can't rely on
any specific locale setting on any Windows user system.
The *W (wide character) functions, however, are (well-)defined and if we
use them correctly this should always work correctly.
Perhaps the right thing is to make a wrapper fl_open() (we don't
have one presently I don't think)
Yep, that and only that, if you ask me. I wonder why we didn't detect
the missing fl_open() wrapper yet. We have wrappers for "everything",
even fl_access(), fl_getenv(), fl_putenv(), ... And yes, environment
variables are also concerned.
The Windows API requires either an "Ansi" character string (i.e. current
codepage) or a "Unicode" aka "Wide Character" string (UTF-16). This is
implemented by either the 'A' suffix or the 'W' suffix of function names
whereas the function name w/o the suffix uses a trick with a definition
of Unicode or similar macro or whatever.
We're *always* using the *W function names explicitly where applicable
to avoid ambiguities.
and have it detect use the UTF8 -> WC conversion only when needed,
so that we can open files with utf8 strings.
In that case conversion == detection. If it's not necessary (7-bit ASCII
only) the converted string is identical to the original string.
A separate detection pass would only add complexity.
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?
It's definitely runtime, you must call the *W function and provide a
UTF-16 string. UTF-8 with non-ASCII contents will always fail.
One thing seems sure; open() doesn't handle utf8 pathnames on Windows.
I did a short test with a utf8 encoded subdirectory ...
...
I was able to get _wopen() to work in mingw by modifying that
program to use a wchar_t string,
How? Did you convert the UTF-8 string or how did you provide a wchar_t
string? Which encoding? Maybe with L"string" syntax? Yes, that would be
UTF-16 encoded and work with _wopen().
so it does seem to be an issue with the windows implementation of
open()/_open().
Absolutely correct. I'm not sure what the real difference is (I think
only MS would know) but in our context both would do the wrong thing if
provided with UTF-8 (non-ASCII) strings.
--
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/730670dc-4016-7978-c739-2bf8c3ca6d7d%40online.de.
[ Direct Link to Message ] | |
|
| |
