1. Home
  2. Electronics (German)
  3. STM32, CooCox CoIDE, GCC, merkwürdiger Effek t mit Umlauten

STM32, CooCox CoIDE, GCC, merkwürdiger Effek t mit Umlauten

Hallo, ich habe hier einen merkwürdigen Effekt mit der CooCox CoIDE festgestellt.

wenn ich

---------------------- unsigned char b; b = 'ä'; // b = umlaut a

----------------------

ausführe, hat b anschließend nicht den Dezimalwert 132, wie erwartet, sondern 228.

Wenn ich im Editorfenster der IDE 132 eingebe, erscheint wie erwartet das kleine 'ä'.

Irgendwie scheint der Compiler da den Zeichensatz zu verwurschteln.

Wir können und jetzt behelfen, indem wir

------------------- if (b=='ä') b=132;

-------------------

aufrufen, aber das finde ich irgendwie bescheuert. Mit den anderen Umlauten haben wir ein vergleichbares Problem.

Gibt es da eine Option im Compiler, oder in der IDE?

Gruß

Stefan

Reply to
Stefan
Loading thread data ...

Stefan schrieb:

228 ist doch der Code für 'ä' in ISO 8859(-1) und in Windows-1252. Bestimmt speichert die IDE den Quellcode in dieser Zeichencodierung. Warum sollte sie irgendeine MS-DOS Codepage verwenden, in der 'ä' einmal 132 war?

Christian

--
Christian Zietz  -  CHZ-Soft  -  czietz (at) gmx.net 
WWW: http://www.chzsoft.de/ 
PGP/GnuPG-Key-ID: 0x6DA025CA
Reply to
Christian Zietz

Am 24.05.2013 08:42, schrieb Christian Zietz:

Ich war davon ausgegangen, dass der Editor wenn ich 132 eingebe und der Editor ein 'ä' anzeigt, dieses auch als Zeichen 132 gespeichert wird.

Gruß

Stefan

Reply to
Stefan

Stefan schrieb:

Das ist bestimmt ein Vorzeichenproblem, was passiert denn, wenn Du "b" als "int" deklarierst? Normalerweise sind Zeichen ja "char" und nicht "unsigned char" und als char kann 'ä' nicht den Dezimalwert 132 annehmen, weil der Wertebereich von -127 bis +128 geht.

Reply to
Edzard Egberts

Am 24.05.2013 09:02, schrieb Edzard Egberts:

Nein, als unsigned char geht der Wertebereich von 0-255.

Die Antwort von Christian war schon korrekt. Offenbar arbeitet GCC bzw. die CooCox CoIDE mit dem ISO 8859 Zeichensatz.

Gruß

Stefan

Reply to
Stefan

Stefan schrieb:

Windows übersetzt aus Kompatibilitätsgründen diese Eingaben aus MS-DOS-Zeiten in die jeweilige Zeichencodierung. Gib mal 0228 ein...

Christian

PS: Die 'ä' in Deinem Posting sind auch alle als 228 codiert. Oh nein!

--
Christian Zietz  -  CHZ-Soft  -  czietz (at) gmx.net 
WWW: http://www.chzsoft.de/ 
PGP/GnuPG-Key-ID: 0x6DA025CA
Reply to
Christian Zietz

Stefan schrieb:

Vertan, -128 bis 127 ist richtig.

Das ist mir schon klar, ich dachte z.B. an so etwas:

unsigned char b= 'ä'; if (b == 'ä') // ist immer false, weil bei der Zuweisung gecastet wurde

Die Arbeit mit "unsigned char" kann tückisch sein, wenn man mit "signed char" mischt.

Okay, in die falsche Codepage geguckt, ist natürlich die ganz einfache Lösung. ;o)

Reply to
Edzard Egberts

Stefan schrieb:

vielleicht hilft Dir das weiter:

mit >ALT 132< kommt das ascii - ä raus. mit >ALT 0228< kommt das ansi - ä raus.

Gruß Andreas

Reply to
Andreas Fecht

Andreas Fecht schrieb:

Interessant, wie stellt man das den bei einem 7-Bit-Code wie ASCII dar? ASCII-ä war nach ISO-646 in Deutschland 123.

Gruß Willi

Reply to
Willi Marquart

Willi Marquart schrieb:

Andreas hat nur ASCII mit DOS verwexelt - was für viele Leute scheinbar

synonym ist.

(und ISO-646 mit seinen unzähligen Ländervarianten kennt heute eh kau m noch jemand...)

Tilmann

Reply to
Tilmann Reh

Wieso (immer)?

Hint: es gibt Architekturen, wo "char" unsigned ist.

cu Michael

Reply to
Michael Schwingen

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.