Edward Welbourne wrote:
> clang, gcc read input the same with LC_ALL unset and set variously to C,
> POSIX, en_US, pt_BR, el_GR. I note that none of these explicitly
> selects an encoding, so the doc above is indeed consistent with gcc
> guessing UTF-8 based on the value of LC_ALL. Even if the only el_GR or
> pt_BR locale your host actually has the necessary data compiled for are
> the ones using an encoding incompatible with UTF-8, gcc need not have
> actually checked that if it - like QSystemLocaleData on Unix - only
> looks at the value of environment variables.
If you do not explicitly add ".UTF-8", glibc always gives you the obsolete
legacy locale with the locale-specific pre-Unicode character set. This is
intentional for backwards compatibility. So you should never use a locale
without a ".UTF-8" suffix, unless, like Thiago, you want to deliberately
test what happens in a legacy non-UTF-8 locale.
The locales are interpreted by glibc. Anything that assumes that a given
locale uses a character set different from what glibc actually uses for that
locale is broken. (But it looks like GCC doesn't assume anything about the
locale and just always uses UTF-8 to begin with, contrary to what the
documentation claims.)
Kevin Kofler
_______________________________________________
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
