warning: multi-character character constant [-Wmultichar]

[M. K. (sylaina)]

Ich erhalte bei der Prüfung eines Chars die obige Warnung (avr-gcc 
4.8.1). Mein Code dazu:

...
void lcd_putc(unsigned char c){
  if( c != 'ü') {
  ...
}
...

Aber warum? Wo genau ist da das Problem? Irgendwie sehe ichs nicht.

[Peter II (Gast)]

M. K. schrieb:
> Aber warum? Wo genau ist da das Problem? Irgendwie sehe ichs nicht.

du hast eine Unicode Datei erzeugt.

eine 'ü' abhängig von der Codepage. kann auf jeden System etwas anders 
sein.

[M. K. (sylaina)]

Davon hab ich mal wieder keine Ahnung aber du hast recht, Peter. Habs 
auf non-lossy ASCII umgestellt und das Warning ist weg.

[Johann L. (gjlayde)]

M. K. schrieb:
>   if (c != 'ü')

Weil in dem von dir gewählten Charset 'ü' mehr als 1 Byte belegt, etwa 
wie in

>   if (c != 'ab')

'ab' (nicht: "ab") ist gemäß C eine "multi-character character 
constant".

[Rufus Τ. F. (rufus)]

Hintergrund:

Der Quelltext ist mit utf-8 codiert. Zeichen, die nicht in den 
7-Bit-ASCII-Zeichensatz passen, werden mit (mindestens) zwei Bytes 
codiert.

Damit ist die "char"-Konstante 'ü' größer als ein Byte.

Es gibt auch 8-Bit-Codierungen, in denen Umlaute verwendet werden 
können, eine verbreitete ist "Windows-ANSI", auch "ISO8859-1", "Latin-1" 
oder "CP 1252" ("CP" steht für code page) genannt.

Wenn der Quelltext statt mit utf-8 in dieser Codierung vorliegen würde, 
wäre die "char"-Konstante 'ü' ein Byte groß.

Wenn man allerdings mit "code pages" arbeitet, muss auch das Zielsystem 
mit der gleichen "code page" arbeiten. Die Windows-Konsole verwendet aus 
historischen Gründen standardmäßig aber die DOS-Codepage 850 bzw. 437, 
in der Umlaute komplett anders codiert sind.

Jetzt muss man entweder im Programm mit der Win32-API-Funktion 
SetConsoleOutputCP die gewünschte Codepage einstellen oder aber das 
von Hand vor dem Aufruf des Programmes in der Konsole machen (mode con 
cp select=nummer).

Das Resultat kann aber trotzdem bescheiden aussehen, wenn in der 
Windows-Konsole ein Pixelfont verwendet wird (Standard in allen 
Windows-Versionen vor Windows 10). Dieser kann nur die Zeichen aus der 
DOS-Codepage darstellen ... Umlaute funktionieren, aber komplizierteres 
wie die hochgestellte 3 sind nicht möglich.

Damit das geht, muss man die Konsole dazu bringen, eine Truetypeschrift 
zu verwenden (Lucida Console oder Consolas).

Auf Englisch nennt man das resultierende Thema aus gutem Grund "a can of 
worms".

[Rolf M. (rmagnus)]

Rufus Τ. F. schrieb:
> Es gibt auch 8-Bit-Codierungen, in denen Umlaute verwendet werden
> können, eine verbreitete ist "Windows-ANSI", auch "ISO8859-1", "Latin-1"
> oder "CP 1252" ("CP" steht für code page) genannt.

Wobei seit der Einführung des Euro eher ISO-8859-15 gebräuchlich ist, 
weil das das Euro-Symbol enthält.

> Wenn der Quelltext statt mit utf-8 in dieser Codierung vorliegen würde,
> wäre die "char"-Konstante 'ü' ein Byte groß.

Nicht der Quelltext muss in dieser Codierung vorliegen, sondern sie muss 
als execution character set gewählt sein. Es gibt in C eine Trennung 
zwischen dem "source character set", in dem der Quellcode verfasst ist 
und dem "execution character set", das zur Laufzeit auf dem System 
genutzt wird, wo der Code ausgeführt wird. Bei gcc kann man diese beiden 
mit den Optionen -finput-charset und -fexec-charset angeben.
Für den obigen Fall würde man also

-finput-charset=utf-8 -fexec-charset=iso-8859-15

den Compiler-Optionen hinzufügen.

[Rufus Τ. F. (rufus)]

Danke für die Vervollständigung.

[M. K. (sylaina)]

Rolf M. schrieb:
> Bei gcc kann man diese beiden
> mit den Optionen -finput-charset und -fexec-charset angeben.
> Für den obigen Fall würde man also-finput-charset=utf-8
> -fexec-charset=iso-8859-15
> den Compiler-Optionen hinzufügen.

Das ist ja interessant, das werde ich mal bei Gelegenheit ausprobieren. 
Meine IDE legt nämlich neue Dateien automatisch als UTF-8 an, ich kam 
noch nicht dazu zu schaun wo ich das ändern kann.