ich habe bei meinen gcc programmen inzwischen eine solche Vielzahl von
Warnungen, dass die Suche nach den errors erheblich erschwert wird.
Wie kann ich die Warnungen ganz abschalten
In meiner mf-Vorlage steht eine OPtion
-Wall...: warning level
Wie bringe ich den warning level auf 0?
CFLAGS += -Wall
Einfach rausnehmen?
leluno schrieb:> ich habe bei meinen gcc programmen inzwischen eine solche Vielzahl von> Warnungen, dass die Suche nach den errors erheblich erschwert wird.
Die Warnungen abzuschalten ist hier der falsche Weg.
Warnungen sind potentielle Fehler, beseitige die Warnungen und blende
sie nicht aus.
Ein anständig geschriebenes Programm erzeugt keine Warnungen (außer
vielleicht Spitzfindigkeiten in der allerhöchsten Pedantenstufe, dann
aber auch nicht viele davon).
leluno schrieb:> ich habe bei meinen gcc programmen inzwischen eine solche Vielzahl von> Warnungen, dass die Suche nach den errors erheblich erschwert wird.>> Wie kann ich die Warnungen ganz abschalten>> In meiner mf-Vorlage steht eine OPtion> -Wall...: warning level>> Wie bringe ich den warning level auf 0?
Das ist die falsche Vorgehensweise.
So gut wie alle Warnungen haben einen ernsten Hintergrund. Nicht selten
ist es so, dass die Warnung tatsächlich einen Fehler beschreibt.
Der richtige Weg ist es daher, den Code so umzuändern, dass die
Warnungen verschwinden. In der professionellen Software-Entwicklung gilt
bei den meisten Firmen der Grundsatz: Auf höchstem Warning Level darf es
keine einzige Warnung geben. Und dabei ist es egal, ob wir von 100 Lines
Of Code sprechen oder von 2 Millionen.
Und ja: Bei einer neuen Compiler-Version, die dann noch mehr
zweifelhafte Stellen anwarnt, bedeutet das, das der Code überarbeitet
werden muss.
leluno schrieb:> ich habe bei meinen gcc programmen inzwischen eine solche Vielzahl von> Warnungen, dass die Suche nach den errors erheblich erschwert wird.
Mit Warnungen sagt Dir der Compiler, Du hast ein schweres Foul begangen,
was Du korrigieren solltest.
Er kann dann zwar noch ein Binary erzeugen, welches aber in der Regel
nicht erwartungsgemäß funktioniert.
Mit Errors sagt er Dir, Du hast einen solchen dermaßenen Unsinn
verzapft, daß es ihm unmöglich ist, ein Compilat zu erzeugen.
Ingo Korb schrieb:> leluno schrieb:>> Wie bringe ich den warning level auf 0?>> Fang mit "CFLAGS += -Wall -Werror" an.
ich rate zu "-Wall -Wextra -Werror"
ansonsten schließe ich mich dem Rest an: den Compiler so pedantisch wie
möglich (-Wall -Wextra) einstellen, und dann die Warnings im Code fixen.
Die einzige Warning die ich manchmal abstelle, ist "strict aliasing"
leluno schrieb:> ich habe bei meinen gcc programmen inzwischen eine solche Vielzahl von> Warnungen, dass die Suche nach den errors erheblich erschwert wird.>> Wie kann ich die Warnungen ganz abschalten
Fragst du dann als nächstes, wie du den Virenscanner deaktivieren
kannst, weil er dich dauernd damit nervt, daß er irgendwelche Viren
gefunden hat?
Das wäre genauso, als wenn man in der Schule die Prüfungsfragen
einfacher gestaltet. Klar hebt man dadurch den Notendurchschnitt an und
die Schule steht besser da (PISA läßt grüßen), aber die Schüler werden
deshalb nicht klüger.
Vielen Dank für die hilfreichen Antworten..
Ich habe über Seiten Warnungen wie folgt:
197: warning: pointer targets in passing argument 1 of 'GUI_Text' differ
in signedness
heizung.h:198: warning: pointer targets in passing argument 1 of
'GUI_Text' differ in signedness
heizung.h:205: warning: pointer targets in passing argument 1 of
'GUI_Text' differ in signedness
heizung.h:205: warning: pointer targets in passing argument 1 of
'GUI_Text' differ in signedness
heizung.h:230: warning: pointer targets in passing argument 1 of
'GUI_Text' differ in signedness
heizung.h:230: warning: pointer targets in passing argument 1 of
'GUI_Text' differ in signedness
heizung.h:231: warning: pointer targets in passing argument 1 of
'GUI_Text' differ in signedness
heizung.h:231: warning: pointer targets in passing argument 1 of
'GUI_Text' differ in signedness
heizung.h:232: warning: pointer targets in passing argument 1 of
'GUI_Text' differ in signedness
heizung.h:232: warning: pointer targets in passing argument 1 of
'GUI_Text' differ in signedness
heizung.h:233: warning: pointer targets in passing argument 1 of
'GUI_Text' differ in signedness
heizung.h:233: warning: pointer targets in passing argument 1 of
'GUI_Text' differ in signedness
heizung.h:236: warning: pointer targets in passing argument 1 of
'GUI_Text' differ in signedness
heizung.h:236: warning: pointer targets in passing argument 1 of
'GUI_Text' differ in signedness
heizung.h:237: warning: pointer targets in passing argument 1 of
'GUI_Text' differ in signedness
heizung.h:237: warning: pointer targets in passing argument 1 of
'GUI_Text' differ in signedness
heizung.h:238: warning: pointer targets in passing argument 1 of
'GUI_Text' differ in signedness
heizung.h:238: warning: pointer targets in passing argument 1 of
'GUI_Text' differ in signedness
heizung.h:239: warning: pointer targets in passing argument 1 of
'GUI_Text' differ in signedness
heizung.h:239: warning: pointer targets in passing argument 1 of
'GUI_Text' differ in signedness
heizung.h:241: warning: pointer targets in passing argument 1 of
'GUI_Text' differ in signedness
heizung.h:241: warning: pointer targets in passing argument 1 of
'GUI_Text' differ in signedness
heizung.h:242: warning: pointer targets in passing argument 1 of
'GUI_Text' differ in signedness
heizung.h:242: warning: pointer targets in passing argument 1 of
'GUI_Text' differ in signedness
heizung.h:243: warning: pointer targets in passing argument 1 of
'GUI_Text' differ in signedness
heizung.h:243: warning: pointer targets in passing argument 1 of
'GUI_Text' differ in signedness
heizung.h: At
dass hier irgendwo ein unsigned Wert übergeben wird obwohl -warum auch
immer - ein signed Typ verlangt wird, weiß ich auch. Der Fehler ist von
mir nicht zu finden. Interessiert mich auch nicht weiter, weil die
Funktion gut funktioniert.
Muss ich mich von gcc nun wirklich ständig über das Vorhandensein dieses
dämlichen Fehlers belehren lassen, oder kann man das irgendwo
abschalten?
Dass ich eigentlich sowieso zu blöde bin, ist mir inzwischen völlig
bewusst. Es muss daher nicht mit jedem Kommentar ausdrücklich wiederholt
werden.
leluno schrieb:> Der Fehler ist von mir nicht zu finden.
Wieso? Das ist doch nun wirklich einfach - sieh Dir die Deklaration
der Funktion an, und sieh Dir an, wie sie aufgerufen wird.
leluno schrieb:> Muss ich mich von gcc nun wirklich ständig über das Vorhandensein dieses> dämlichen Fehlers belehren lassen, oder kann man das irgendwo> abschalten?
Nein, mußt du nicht. Nur hartnäckig bleiben und EINMAL den Fehler
finden. Er ist nunmal da und man kann ihn sicher auch finden. Ich denke
mal, bestimmt auch mit Hilfe des Forums. Aber einfach ignorieren ist die
denkbar schlecheste Lösung. Auch wenn du jetzt keine Auswirkung spürst,
irgendwann wird dir das bestimmt in einem anderen Zusammenhang uf die
Füße fallen.
kann es sein das du den quelltext in eine *.h datei schreibst?
> heizung.h:242: ...> heizung.h:243: ...
das diese Meldung für verschiende Zeilen in einem header kommt, ist sehr
merkwürdig.
leluno schrieb:> Vielen Dank für die hilfreichen Antworten..> Ich habe über Seiten Warnungen wie folgt:
Das ist doch eh immer dergleiche Fehler.
Höchst wahrscheinlich reicht es aus, sich die Deklaration der Funktion
anzusehen, sich zu überlegen wo da ein mogliches Vorzeichen reinkommt
(wahrscheinlich ist auf deinem System ein char implizit ein signed char
und in der Funktionsdeklaration steht unsigned char), das 'Problem' zu
fixen und mit 3 Minuten Aufwand sind 380 Warnungen vom Tisch.
> immer - ein signed Typ verlangt wird, weiß ich auch. Der Fehler ist von> mir nicht zu finden.
Echt nicht?
Du könntest was dabei lernen, wenn du dich mit den Hintergründen
beschäftigst.
Es gibt 3(!) char Varianten
1
signed char
2
unsigned char
3
char
wobei klar ist, dass ein 'char' entweder ein 'signed char' oder ein
'unsigned char' sein muss. Das Problem: welches von beiden zutrifft
entscheidet der Compiler.
Halte dich an die simple Verwendungshilfe
1
signed char kleine Zahlen mit Vorzeichen
2
unsigned char kleine Zahlen ohne Vorzeichen
3
char Textverarbeitung
und du hast weniger Probleme.
eine Funktion
1
voidGUI_Text(unsignedchar*text);
ist daher Unsinn. Das ist ganz klar eine Funktion, die in die Kategorie
Textverarbeitung fällt. Daher
1
voidGUI_Text(char*text);
Und höchst wahrscheinlich ist dein 'Problem' an dieser Stelle damit vom
Tisch.
Es kann aber auch genau anders rum sein. Die Funktion ist schon
1
voidGUI_Text(char*text);
und du rufst sie so auf
1
unsignedcharbuffer[10];
2
3
GUI_Text(buffer);
Auch da hast du dann unter Umständen eine unterschiedliche Signedness.
Die Lösung verrät uns wieder Daumenregel-Tabelle: buffer muss ein 'char'
sein. Kein 'signed char', kein 'unsigned char'. Denn, du errätst es
schon: Auch hier hat man es ja wieder mit Textverarbeitung im weitesten
Sinne zu tun.
> Interessiert mich auch nicht weiter
Sollte dich aber interessieren. Denn nicht alle Warnungen sind so
trivial. Sowohl in der Beseitigung als auch in den Auswirkungen.
vielleicht noch eine Meinung vom Nicht-Experten: Beim ersten make mit
-Wextra dachte ich noch "der spinnt doch, der gcc, die Warnungen bringe
ich nie raus", aber die Fleißarbeit hat sich wirklich gelohnt. Dabei
sind durchaus auch echte Fehler aufgekommen. Mit "-O" gibt's auch noch
meine Lieblings-Warnung "'foo' may be used uninitialized in this
function", aber man kann den Assembler-Output trotzdem noch lesen.
Ich spendiere auch noch ein "-pedantic", was haltet ihr davon?
-pedantic kann man aus Spaß mal nutzen, um zu verstehen, was das alles
anmmeckert. Das erlaubt nur striktes ISO-C, die Einschränkung will man
aber nicht immer haben.
Oliver
Ich wäre ja schon dankbar, wenn mir jemand sagen würde, dass man die
Warnungen aus pädagogischen Gründen nicht abschalten kann.
Die beanstandete Funktion sieht so aus:
//==================================================
void GUI_Text(uint8_t *str)
{
uint8_t TempChar;
do
{
TempChar = *str++;
if(TempChar<' '||TempChar>130)return;
PutChar(TempChar);
curposx =curposx+ f_width;
if(frame)curposx++;
//relposx=relposx+ f_width;
}
while ( *str != 0 );
}
leluno schrieb:> Ich wäre ja schon dankbar, wenn mir jemand sagen würde, dass man die> Warnungen aus pädagogischen Gründen nicht abschalten kann.
Nicht ganz. Aus pädagogischen Gründen sagen wir dir erst, wie man die
Warnung abschalten kann, wenn du das Problem in deinem Code behoben
hast.
Denn ja, man kann die abschalten...
Oliver
leluno schrieb:> TempChar = *str++
Das ist aber auch eine merkwürdige Konstruktion....
...und wenn char signed ist und uint8_t nicht hast Du auch schon Deinen
Fehler.
Oliver schrieb:> Nicht ganz. Aus pädagogischen Gründen sagen wir dir erst, wie man die> Warnung abschalten kann, wenn du das Problem in deinem Code behoben> hast.>> Denn ja, man kann die abschalten...>> Oliver
Nachdem der Fehler jetzt behoben ist...
leluno schrieb:> Oliver schrieb:>> Nicht ganz. Aus pädagogischen Gründen sagen wir dir erst, wie man die>> Warnung abschalten kann, wenn du das Problem in deinem Code behoben>> hast.>>>> Denn ja, man kann die abschalten...>>>> Oliver>> Nachdem der Fehler jetzt behoben ist...
:-)
... brauchst du sie nicht mehr abschalten. Denn die nächste Warnung
lauert bereits in den Startlöchern um dich auf ein potentielles Problem
in deinem Code hinzuweisen. Wenn die Warnung da ist, behebst du das
Problem. Wenn du von alleine nicht drauf kommst, was das Problem ist,
dann frag nach.
Das sind dann 2 Fliegen mit einer Klappe: zum einen verschwindet die
Warnung, zum anderen verbesserst du dein C.
leluno schrieb:> 197: warning: pointer targets in passing argument 1 of 'GUI_Text' differ> in signedness
Diese Warnung rührt daher, daß in grauen Vorzeiten Zeichen als char
definiert wurden und sich niemand traut, das mal richtig zu biegen, also
wenigstens auch unsigned char oder uint8_t zuzulassen.
Negative Zeichen sind allerdings Schwachsinn und verhindern z.B. eine
Umwandlung von ASCII-Umlauten in LCD-Umlaute, weil char >127 nicht geht.
Man muß nun leider mit diesem Schwachsinn leben und alle Zeichen als
char anlegen, selbst int8_t ist nicht erlaubt.
Und dann ständig im Hinterkopf behalten, daß man bei Vergleichen >127
für sich ganz heimlich im stillen Kämmerlein temporär doch erstmal nach
uint8_t casten muß.
leluno schrieb:> Oliver schrieb:>> Nicht ganz. Aus pädagogischen Gründen sagen wir dir erst, wie man die>> Warnung abschalten kann, wenn du das Problem in deinem Code behoben>> hast.>>>> Denn ja, man kann die abschalten...>>>> Oliver>> Nachdem der Fehler jetzt behoben ist...
Aber nur, wenn du versprichst, hier immer erst nachzufragen. bevor du
abschaltest ;)
Mit -Wno-xxxxxxxx lässt sich gezielt jede Warnung abschalten. Genaures
dazu steht in der gcc-Doku - und aus pädagogischen Gründen liest du das
bitte selber nach. Denn solche Infos in der Doku zu finden und zu lesen
ist auch eine der unabdingbaren Grundvoraussetzung...
Oliver
Peter Dannegger schrieb:> Man muß nun leider mit diesem Schwachsinn leben und alle Zeichen als> char anlegen, selbst int8_t ist nicht erlaubt.
danke für diese Erklärung. der code wurde aus einem ARM-Projekt kopiert.
Da gelten möglicherweise andere Regeln
Peter Dannegger schrieb:> leluno schrieb:>> 197: warning: pointer targets in passing argument 1 of 'GUI_Text' differ>> in signedness>> Diese Warnung rührt daher, daß in grauen Vorzeiten Zeichen als char> definiert wurden und sich niemand traut, das mal richtig zu biegen, also> wenigstens auch unsigned char oder uint8_t zuzulassen.
Es gibt nichts geradezubiegen. char ist für Zeichen, PUNKT!
> Negative Zeichen sind allerdings Schwachsinn und verhindern z.B. eine> Umwandlung von ASCII-Umlauten in LCD-Umlaute, weil char >127 nicht geht.
Wie bei so ziemlich jeder Sprache muß man halt an der einen
Schnittstelle, an der es zur Hardware geht, vom Zeichentyp in einen
entsprechenden Integer-Typ konvertieren. Warum damit so viele Leute ein
Problem haben, verstehe ich ehrlich gesagt nicht.
> Man muß nun leider mit diesem Schwachsinn leben und alle Zeichen als> char anlegen, selbst int8_t ist nicht erlaubt.
Das ist ein ganz normales Konzept in der Programmierung.
Rolf Magnus schrieb:> Das ist ein ganz normales Konzept in der Programmierung.
Zeichen sind char, einverstanden.
Wenn man aber Zeichen so verwenden möchte, daß man auch den Zeichensatz
ausnutzt, dann muß man erst nach uint8_t casten, was ja per Definition
gar kein Zeichen ist? Und das nennst du normal?
Es ist nun mal so, das kann man nicht ändern, aber normal ist es
trotzdem nicht :-)
GCC schrieb:> Wenn man aber Zeichen so verwenden möchte, daß man auch den Zeichensatz> ausnutzt, dann muß man erst nach uint8_t casten, was ja per Definition> gar kein Zeichen ist? Und das nennst du normal?>> Es ist nun mal so, das kann man nicht ändern, aber normal ist es> trotzdem nicht :-)
Muss man ja nicht.
Alle (mir bekannten) char-funktionen arbeiten problemlos mit dem vollen
Bereich 0..255 (oder -128..127, je nachdem)
Wichtig ist nur, dass man konsequent immer das gleiche verwendet,
entweder signed oder unsigned. oder das dem Compiler überlässt, indem
man das "signed/unsigned" einfach weglässt.
Insofern führt die Daumenregel "zeichen = char ohne was" automatisch zum
richtigen Ergebnis.
leluno schrieb:> der code wurde aus einem ARM-Projekt kopiert.> Da gelten möglicherweise andere Regeln
Nein, da gelten die selben Regeln. Allerdings waren (sehr viel) ältere
gcc's da etwas großzügiger, und haben an solchen Stellen nicht gewarnt.
Wenn das Projekt also schon älteren Datums ist, ließ sich das zu seiner
Enstehungszeit wohl warnungsfrei compilieren. Richtig wars deshalb aber
nicht.
Oliver
GCC schrieb:> Zeichen sind char, einverstanden.> Wenn man aber Zeichen so verwenden möchte, daß man auch den Zeichensatz> ausnutzt, dann muß man erst nach uint8_t casten, was ja per Definition> gar kein Zeichen ist? Und das nennst du normal?>> Es ist nun mal so, das kann man nicht ändern, aber normal ist es> trotzdem nicht :-)
Richtig.
Normal ist, dass man in streng typisierten Sprachen eine
Konvertierfunktion benutzen muss, um zwischen dem internen Typ Character
und der Repräsentierung des Zeichens durch seinen Code hin und her
wechseln zu können.
In Pseudocode unter Anlehung an andere Sprachen
1
int code;
2
char character;
3
4
character = chr( 148 );
5
code = asc( character );
besser?
kommt drauf an.
das allseits beliebte Konstrukt um 1 digit in seinen ASCII Code zu
verwandeln
1
charc;
2
intdigit=5;
3
4
c=digit+'0';
schreibt sich dann als
1
c = chr( digit + asc( '0' ) );
na, ich weiß nicht. Da rechne ich dann doch lieber in Ausnahmefällen
direkt mit einem char.
GCC schrieb:> Rolf Magnus schrieb:>> Das ist ein ganz normales Konzept in der Programmierung.>> Zeichen sind char, einverstanden.> Wenn man aber Zeichen so verwenden möchte, daß man auch den Zeichensatz> ausnutzt, dann muß man erst nach uint8_t casten, was ja per Definition> gar kein Zeichen ist?
Warum sollte man das müssen? char hat (mindestens) 8 Bit, und die kann
ich voll nutzen, völlig egal, wie der darunterliegende Integer-Typ
aussieht. Der interessiert mich gar nicht.
Michael Reinelt schrieb:> Alle (mir bekannten) char-funktionen arbeiten problemlos mit dem vollen> Bereich 0..255 (oder -128..127, je nachdem)
Na da bin ich ja mal gespannt, was eine Zeichensatztabelle auf dem GLCD
ausgibt, wenn Du mit dem Index -128 drauf zugreifst.
1
voidputchar(charc)
2
{
3
for(uint8_ti=0;i<5;i++)
4
write_glcd(font_5x7[c][i]);
5
}
6
// ...
7
putchar('Ü');
Sobald man Zeichen nicht nur kopiert, sondern auch verarbeiten will,
fallen einem die negativen Zeichen ständig auf die Füße.
Peter Dannegger schrieb:> da bin ich ja mal gespannt, was eine Zeichensatztabelle auf dem GLCD> ausgibt, wenn Du mit dem Index -128 drauf zugreifst.
Ich weiß zwar, daß Du deutlich mehr C-Experte als ich bist, aber gibt es
irgendeine sinnvollere Vorgehensweise als einfach eine Funktion zu
definieren, die die Codepage verarbeitet? Spätestens bei Sonderzeichen
kenne ich da keinen sinnvollen Weg mehr drumherum. Und dann ist es nur
noch die Frage, wie man den Offset definiert.
Peter Dannegger schrieb:> Sobald man Zeichen nicht nur kopiert, sondern auch verarbeiten will,> fallen einem die negativen Zeichen ständig auf die Füße.
Wer char ohne cast als Index nimmt, ist halt selbst schuld.
Weil es kein Offset ist, heißt es ja char, und nicht offset_t.
Es bleibt dabei: für Zeichen nimmt man char, und umgekehrt nimmt man
char nicht für etwas anderes als Zeichen.
Peter Dannegger schrieb:> putchar( 'Ü' );
Bei UTF-8-kodiertem Quelltext gibt das ne Warning, da das Ü in UTF-8
zwei Bytes lang ist:
warning: multi-character character constant [-Wmultichar]
warning: overflow in implicit constant conversion [-Woverflow]
Bei Encodings die das Ü als ein Byte kodieren, wie Windows-1252 klappt's
natürlich.
Klaus Wachtler schrieb:> Wer char ohne cast als Index nimmt
Die standard Antwort des C-Programmierers: "Nimm einen Cast mehr".
Den Amis ist es eh schnurz, die kommen mit den unteren 127 Zeichen aus.
Schöner wärs halt, wenn man es mal richtig gemacht hätte.
Dann müßte nicht erst jeder nicht englischsprachige Programmieranfänger
von neuem darauf hereinfallen.
Und das dürfte früher auch das Hauptproblem bei der Versionierung von
Windows und Anwendungen für verschiedene Länder gewesen sein.
Peter Dannegger schrieb:> Michael Reinelt schrieb:>> Alle (mir bekannten) char-funktionen arbeiten problemlos mit dem vollen>> Bereich 0..255 (oder -128..127, je nachdem)>> Na da bin ich ja mal gespannt, was eine Zeichensatztabelle auf dem GLCD> ausgibt, wenn Du mit dem Index -128 drauf zugreifst.
Wie schon gesagt: An der einen Stelle, wo man das ganze an die Hardware
übergibt, also in deinem Fall in putchar, macht man dann einen uint8_t
draus. Es wäre in anderen Sprachen in der Regel auch nicht anders. Da
reicht nur ein einfacher Cast meist nicht, sondern es gibt extra eine
Funktion dafür, die man aufrufen muss.
Peter Dannegger schrieb:> Klaus Wachtler schrieb:>> Wer char ohne cast als Index nimmt>> Die standard Antwort des C-Programmierers: "Nimm einen Cast mehr".
Wenn du char richtig verwendest, hast du an einer einzigen Stelle,
nämlich der low-level-Schnittstelle einen Cast. Es ist nicht so, als ob
du dafür deinen kompletten Code mit Casts spicken müßtest. Das passiert
erst dann, wenn du überall uint8_t statt char verwendest. Dann hagelt es
eben wie beim Ursprungsposter auf einmal massenhaft Warnungen, wenn man
mit String- oder Zeichenkonstanten oder Standard-Stringfunktionen
arbeitet. Da bräuchte man dann tatsächlich jede Menge Casts, um den
Compiler ruhigzustellen.
Peter Dannegger schrieb:> Klaus Wachtler schrieb:>> Wer char ohne cast als Index nimmt>> Die standard Antwort des C-Programmierers: "Nimm einen Cast mehr".>> Den Amis ist es eh schnurz, die kommen mit den unteren 127 Zeichen aus.>> Schöner wärs halt, wenn man es mal richtig gemacht hätte.
definiere "richtig"
und achte darauf nicht in denselben Chauvinismus zu verfallen, wie
damals die Amis, als sie 7-Bit ASCII definiert haben. Nur weil für uns
Umlaute wichtig sind, heißt das nicht, dass sie in anderen Sprachen auch
wichtig sind. Was brauchen Skandinavier, Griechen, Franzosen, Italiener,
etc....
Da ist man schnell an der Grenze dessen, was mit einem char ohne
Zusatzdefinition möglich ist.
Chinesen und Japaner nicht vergessen.
Thread beobachten
Seitenaufteilung abschalten