Ich weiß nicht, wie gut diese Optionen tatsächlich funktionieren (nicht mit atm; Ich bevorzuge immer noch String-Literale als 'nur ASCII' zu behandeln, da lokalisierte Strings kommen externe Dateien sowieso so dass es wie Format-Strings oder Dateinamen meist Dinge ist), aber sie haben Optionen hinzugefügt wie
-fexec-charset=charset
Set the execution character set, used for string and character constants. The default
is UTF-8. charset can be any encoding supported by the system's iconv library routine.
-fwide-exec-charset=charset
Set the wide execution character set, used for wide string and character constants.
The default is UTF-32 or UTF-16, whichever corresponds to the width of wchar_t. As
with -fexec-charset, charset can be any encoding supported by the system's iconv
library routine; however, you will have problems with encodings that do not fit
exactly in wchar_t.
-finput-charset=charset
Set the input character set, used for translation from the character set of the
input file to the source character set used by GCC. If the locale does not specify,
or GCC cannot get this information from the locale, the default is UTF-8. This can
be overridden by either the locale or this command line option. Currently the command
line option takes precedence if there's a conflict. charset can be any encoding
supported by the system's iconv library routine.
ich frage mich, ob, wenn die src und exec Codierung der Standard UTF-8 ist, es bestätigt tatsächlich die Stringliteral auch -formed UTF-8 und löst einen Fehler aus, wenn es ungültige Bytefolgen enthält - oder ob nur die ungültigen Bytes durchgelassen werden. –