AVR-GCC: Welcher Zeichensatz?

Natürlich spielt der Zeichensatz eine Rolle. Wenn ich im Quelltext ein 
char mit dem Inhalt 'µ' erzeuge, ist es durchaus von Bedeutung, welchen 
Zahlenwert der Kompiler daraus macht - schließlich muß ich meinen 
Zeichensatz danach auslegen.

Eingebaut ist das Display nicht, aber angehängt. Und einen char kann ich 
ja durchaus als int anzeigen. Muß ich sogar, wenn ich den Zeichensatz 
entwerfe.

Peter II schrieb:
> Der eigentliche Quellcode ist ASCII. Was in "Strings" steht spielt keine
> rolle.

Die DOS-Erweiterung von ASCII ist es schonmal nicht. Da steht "mu" an 
Stelle 230 und an Stelle 181 ist ein Stück Rahmen.

Peter II schrieb:
> Das ist wie ein Tonbandgerät, dem ist auch die Sprache egal.

Der kleine AVR ist auch kein Tonbandgerät. Tonbandgeräte kenne ich noch. 
Die haben keinen Zeichensatz. Die haben nur <<  ■ || > >>, und das auch 
nur aufgedruckt.

Und wenn ich an einem Display einen Zeichensatz habe, der vom AVR 
erzeugt wird, ist es durchaus von Wichtigkeit, welches Zeichen im 
Quelltext zu welcher Zahl im char führen, ansonsten müßte ich nämlich 
jeden Text als Array eingeben. Will ich aber nicht. Mache ich über die 
Tastatur. Nur bei Sonderzeichen ist es interessant, ob das erzeugte 
Zeichen für jede Erzeugerplattform gleich ist. Ansonsten ist der 
Quelltext nicht portabel.

Deswegen ist für mich die Kenntnis des von AVR-GCC genutzten 
Zeichensatzes DOCH interessant. Ich finde es auch nicht schlimm, wenn 
andere das langweilig finden. Ich aber nicht.

Nicolas S. schrieb:
> Deswegen ist für mich die Kenntnis des von AVR-GCC genutzten
> Zeichensatzes DOCH interessant.

Nein, der avr-gcc nimmst wie es kommt.
Was dich interessiert, ist, welchen Zeichensatz dein Editor verwendet. 
Und das lässt sich für gewöhnlich einstellen.

Als C-Programmierer solltest du dir angewöhnen, dass du dich auf den 
originalen ASCII-Zeichensatz berufen darfst. 7-Bit - Kleinbuchstaben, 
Großbuchstaben, Ziffern und ein paar Sonderzeichen.
Alles darüber hinausgehende, insbesondere was bei gesetztem 8. Bit 
rauskommt, ist eine Frage von Gottvertrauen, Editor und hängt nicht 
zuletzt auch davon ab, was dein Ausgabegerät mit diesen Bytes macht.

OK, das heißt also, daß ich mich nicht darauf verlassen kann, daß der 
AVR-GCC auf jedem Rechner den gleichen Zeichensatz nutzt. (Oder 
präziser: Die Eingaben der Textdatei außerhalb des kleinen 
ASCII-Zeichensatzes gleich interpretiert).

Dann bleibt für die Eingabe von Sonderzeichen also nur die Nutzung von 
Escapesequenzen mit dem Zeichen im Oktalcode. Kann ich mit leben. 
Tastatur wäre mir lieber gewesen. Hex wäre mir auch lieber gewesen. So 
sinkt eben stufenweise die Lesbarkeit - wenn's nicht besser geht, geht 
es nicht besser. Aber ob das wirklich nötig ist, wollte ich vorher 
geklärt wissen.

Danke für die Antworten
Nicolas

Nicolas S. schrieb:
> OK, das heißt also, daß ich mich nicht darauf verlassen kann, daß der
> AVR-GCC auf jedem Rechner den gleichen Zeichensatz nutzt.

Das ganze hat nichts mit dem gcc zu tun!


Ein Compiler ist ein Programm welches eine Eingabedatei 'verwurschtet'. 
Welche Zeichen-Codes auch immer der Editor dort abgelegt hat, die werden 
vom Compiler benutzt.

Kann es sein, dass du noch nicht gemerkt hast, dass dein C-Programm, so 
wie du es mit dem Editor schreibst, auch nichts anderes als eine Abfolge 
von Code-Bytes ist? Dein Editor ist so freundlich und schreibt dir 
anstelle der Code Bytes, die zugehörigen Zeichen auf den Bildschirm. 
Aber Code ist Code. Eine C-Datei (oder überhaupt eine Text-Datei)

1

int main()

2

{

3

  return 0;

4

}

ist auf Dateiebene auch nichts anderes als eine Abfolge von ASCII Codes.

Der Compiler liest dieses und was auch immer an Codes in einem String 
vorkommt, das schreibt er so wie es ist, dann auch ins Programm hinein.

> Dann bleibt für die Eingabe von Sonderzeichen also nur die Nutzung von
> Escapesequenzen mit dem Zeichen im Oktalcode. Kann ich mit leben.

Kann man sich organisieren. Zb. Mit Präprozessorhilfe und der Regel, 
dass der Compiler aufeinanderfolgende String-Literale zu einem einzigen 
Literal zusammenfassen muss.

Peter II schrieb:
> wo soll jetzt der unteschied zwischen Hex und Oktalcode sein?

Ganz einfach:

1

fprintf("\265C.net"); // geht

2

fprintf("\xb5C.net"); // geht nicht.

Norbert schrieb:
> Bei mir nutzt der arm-gcc den Zeichensatz welcher der Shell Einstellung
> entspricht.

Nein!
Der vi ist in deinem Beispiel derjenige, der einen Zeichensatz benutzt 
und für die Unterschiede verantwortlich ist.

Peter II schrieb:
> Nicolas S. schrieb:
>> Ganz einfach:
>> fprintf("\265C.net"); // geht
>> fprintf("\xb5C.net"); // geht nicht.
>
>
> oktal muss mit 0 einfangen!

Nein. Ein Octal-Code in einem String ist ein Backslash mit drei Ziffern 
dahinter. \265 ist völlig korrekt.

Nicolas S. schrieb:

> Ganz einfach:
>

1

> fprintf("\265C.net"); // geht

2

> fprintf("\xb5C.net"); // geht nicht.

3

>

Und wenn man es so schreibt

1

#define MUE "\xB5"

2

3

4

...

5

6

  fprintf( MUE"C.net" );

dann kann man das dann (meistens) sogar lesen und alle µ auf einem 
anderen LCD gegen die dort gültigen Codes an einer einzigen Stelle 
zentral austauschen.

Karl Heinz Buchegger schrieb:
> Kann es sein, dass du noch nicht gemerkt hast, dass dein C-Programm, so
> wie du es mit dem Editor schreibst, auch nichts anderes als eine Abfolge
> von Code-Bytes ist? Dein Editor ist so freundlich und schreibt dir
> anstelle der Code Bytes, die zugehörigen Zeichen auf den Bildschirm.
> Aber Code ist Code. Eine C-Datei (oder überhaupt eine Text-Datei)int
> main()
> {
>   return 0;
> }
> ist auf Dateiebene auch nichts anderes als eine Abfolge von ASCII Codes.

Nein, unter dem Blickwinkel habe ich es noch nie betrachtet. Für mich 
wurde aus einem Binärwurst immer erst durch einen definierten 
Zeichensatz ein lesbarer Text. Also war ich bislang davon ausgegangen, 
daß ein Compiler/Präprozessor sich die Sachen erstmal wieder in eine 
Textebene legt, allein um Leerzeichen, Tabs und Zeilenumbrüche zu 
interpretieren. Kompilerbau hatten wir im Maschinenbaustudium nicht.

Sollte es heute abend nicht zu heiß zum nachdenken sein, lasse ich mir 
den Wurm, der sich durch binärzeugs frißt, und dabei binärkode zu 
erzeugt, nochmal in Ruhe durch den Kopf gehen.

Karl Heinz Buchegger schrieb:
> fprintf( MUE"C.net" );

Das ist schön und lesbar.

Peter II schrieb:
> fprintf("\xb5 C.net");

Das erzeugt bei mir ein Leerzeichen zwischen µ und C.

Norbert schrieb:
> char z[] = "\xb5""C.net"

Das probiere ich heute abend auch mal. Hex kriege ich irgendwie besser 
in den Kopf als Oktal.

Um zum Kern der Frage zurückzukommen:

AVR-Studio verwendet als Unterbau das "Microsoft Visual Studio", das 
wiederum verwendet im Editor üblicherweise die sogenannte 
"ANSI"-Codepage (CP1252) - die ist weitestgehend identisch mit ISO 
8859-1*. Das ist bei praktisch allen unter Windows arbeitenden 
Editoren der Standardfall. Neuere Visual-Studio-Varianten (und auch 
der windowseigene Primitiveditor Notepad) unterstützen jedoch auch 
UTF-8.

Die alten "DOS"-Codepages CP437 bzw. CP850 werden zur allgemeinen 
Verwirrung aber weiterhin verwendet - in Konsolenfenstern.

Das lässt sich umschalten (mode con cp select=1252), bringt aber nur 
dann befriedigende Ergebnisse, wenn das Konsolfenster nicht mit dem 
defaultmäßigen Pixelfont betrieben wird -- diese Relikt aus der vorderen 
Altsteinzeit nämlich legt die Zeichencodierung zusätzlich fest.


Dem Compiler ist es weitestgehend wurscht, was er im Quelltext findet - 
alle Zeichencodierungen haben als Schnittmenge den ASCII-Zeichensatz, 
und alle für C oder C++ syntaktisch relevanten Zeichen befinden sich in 
diesem ASCII-Zeichensatz. Wenn in Kommentaren oder Stringkonstanten 
Zeichen auftauchen, die nicht im ASCII-Zeichensatz liegen (Umlaute 
etc.), dann kann der Compiler wahlweise Fehlermeldungen ausgeben, oder 
die im Quelltext vorgefundenen Zeichen so, wie sie sind, durchreichen.

Steht da also in einer Stringkonstante etwas, was im verwendeten 
Texteditor aussieht wie ein µ, dann landet das in exakt derselben Form 
auch im erzeugten Binärcode.

Ob der diesen dann abarbeitende Prozessor die Stringkonstante wiederum 
in lesbarer Form z.B. auf einem LC-Display ausgibt, hängt vom 
Zeichensatz des LC-Displays ab -- da beispielsweise HD44780-Displays 
keine CP1252 verwenden, funktioniert das mit solchen Displays nicht, 
und eine Umsetzungstabelle ist vonnöten.


*) http://de.wikipedia.org/wiki/ISO_8859-1

Endlich mal ne gescheite Antwort nach all dem Halbwissen. Danke.