Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
STM32, CooCox CoIDE, GCC, merkwürdiger Effekt mit Umlauten
17 views
Skip to first unread message
Stefan
May 24, 2013, 2:34:56 AM5/24/13
to
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 <alt>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
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 <alt>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
Christian Zietz
May 24, 2013, 2:42:38 AM5/24/13
to
Stefan schrieb:
> wenn ich
> ----------------------
> unsigned char b;
> b = 'ￜ'; // b = umlaut a
> ----------------------
>
> ausfï¿œhre, hat b anschlieï¿œend nicht den Dezimalwert 132, wie erwartet,
> sondern 228.
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
> wenn ich
> ----------------------
> unsigned char b;
> b = 'ￜ'; // b = umlaut a
> ----------------------
>
> ausfï¿œhre, hat b anschlieï¿œend nicht den Dezimalwert 132, wie erwartet,
> sondern 228.
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
Stefan
May 24, 2013, 2:52:10 AM5/24/13
to
Am 24.05.2013 08:42, schrieb Christian Zietz:
> Stefan schrieb:
>
>> wenn ich
>> ----------------------
>> unsigned char b;
>> b = 'ￜ'; // b = umlaut a
>> ----------------------
>>
>> ausfï¿œhre, hat b anschlieï¿œend nicht den Dezimalwert 132, wie erwartet,
>> sondern 228.
>
> 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
>
Ich war davon ausgegangen, dass der Editor wenn ich <alt>132 eingebe und
> Stefan schrieb:
>
>> wenn ich
>> ----------------------
>> unsigned char b;
>> b = 'ￜ'; // b = umlaut a
>> ----------------------
>>
>> ausfï¿œhre, hat b anschlieï¿œend nicht den Dezimalwert 132, wie erwartet,
>> sondern 228.
>
> 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
>
der Editor ein 'ￜ' anzeigt, dieses auch als Zeichen 132 gespeichert wird.
Gruￜ
Stefan
Edzard Egberts
May 24, 2013, 3:02:53 AM5/24/13
to
Stefan schrieb:
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.
> 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.
Das ist bestimmt ein Vorzeichenproblem, was passiert denn, wenn Du "b"
> festgestellt.
>
> wenn ich
> ----------------------
> unsigned char b;
> b = 'ￜ'; // b = umlaut a
> ----------------------
>
> ausfï¿œhre, hat b anschlieï¿œend nicht den Dezimalwert 132, wie erwartet,
> sondern 228.
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.
Stefan
May 24, 2013, 3:32:43 AM5/24/13
to
Die Antwort von Christian war schon korrekt. Offenbar arbeitet GCC bzw.
die CooCox CoIDE mit dem ISO 8859 Zeichensatz.
Gruￜ
Stefan
Christian Zietz
May 24, 2013, 3:34:28 AM5/24/13
to
Stefan schrieb:
> Ich war davon ausgegangen, dass der Editor wenn ich <alt>132 eingebe und
> der Editor ein 'ￜ' anzeigt, dieses auch als Zeichen 132 gespeichert wird.
Windows ï¿œbersetzt aus Kompatibilitï¿œtsgrï¿œnden diese Eingaben aus
MS-DOS-Zeiten in die jeweilige Zeichencodierung. Gib mal <Alt>0228 ein...
Christian
PS: Die 'ￜ' in Deinem Posting sind auch alle als 228 codiert. Oh nein!
> Ich war davon ausgegangen, dass der Editor wenn ich <alt>132 eingebe und
> der Editor ein 'ￜ' anzeigt, dieses auch als Zeichen 132 gespeichert wird.
MS-DOS-Zeiten in die jeweilige Zeichencodierung. Gib mal <Alt>0228 ein...
Christian
PS: Die 'ￜ' in Deinem Posting sind auch alle als 228 codiert. Oh nein!
Edzard Egberts
May 24, 2013, 3:56:33 AM5/24/13
to
Stefan schrieb:
> Nein, als unsigned char geht der Wertebereich von 0-255.
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.
> Die Antwort von Christian war schon korrekt. Offenbar arbeitet GCC bzw.
> die CooCox CoIDE mit dem ISO 8859 Zeichensatz.
Okay, in die falsche Codepage geguckt, ist natï¿œrlich die ganz einfache
Lï¿œsung. ;o)
> Am 24.05.2013 09:02, schrieb Edzard Egberts:
>> Stefan schrieb:
>>> 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.
>>
>> 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.
Vertan, -128 bis 127 ist richtig.
>> Stefan schrieb:
>>> 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.
>>
>> 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.
> Nein, als unsigned char geht der Wertebereich von 0-255.
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.
> Die Antwort von Christian war schon korrekt. Offenbar arbeitet GCC bzw.
> die CooCox CoIDE mit dem ISO 8859 Zeichensatz.
Lï¿œsung. ;o)
Andreas Fecht
May 24, 2013, 6:41:35 AM5/24/13
to
Stefan schrieb:
mit >ALT 132< kommt das ascii - ￜ raus.
mit >ALT 0228< kommt das ansi - ￜ raus.
Gruￜ Andreas
> 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.
>
vielleicht hilft Dir das weiter:
> festgestellt.
>
> wenn ich
> ----------------------
> unsigned char b;
> b = 'ￜ'; // b = umlaut a
> ----------------------
>
> ausfï¿œhre, hat b anschlieï¿œend nicht den Dezimalwert 132, wie erwartet,
> sondern 228.
>
mit >ALT 132< kommt das ascii - ￜ raus.
mit >ALT 0228< kommt das ansi - ￜ raus.
Gruￜ Andreas
Willi Marquart
May 24, 2013, 7:53:46 AM5/24/13
to
Andreas Fecht schrieb:
>mit >ALT 132< kommt das ascii - � raus.
Interessant, wie stellt man das den bei einem 7-Bit-Code wie ASCII
dar? ASCII-� war nach ISO-646 in Deutschland 123.
Gru� Willi
>mit >ALT 132< kommt das ascii - � raus.
Interessant, wie stellt man das den bei einem 7-Bit-Code wie ASCII
dar? ASCII-� war nach ISO-646 in Deutschland 123.
Gru� Willi
Tilmann Reh
May 24, 2013, 8:04:51 AM5/24/13
to
Willi Marquart schrieb:
> Andreas Fecht schrieb:
>
>>mit >ALT 132< kommt das ascii - ä raus.
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 kaum
noch jemand...)
Tilmann
> Andreas Fecht schrieb:
>
>>mit >ALT 132< kommt das ascii - ä raus.
>
> Interessant, wie stellt man das den bei einem 7-Bit-Code wie ASCII
> dar? ASCII-ä war nach ISO-646 in Deutschland 123.
> Interessant, wie stellt man das den bei einem 7-Bit-Code wie ASCII
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 kaum
noch jemand...)
Tilmann
Michael Schwingen
May 25, 2013, 1:44:29 PM5/25/13
to
On 2013-05-24, Edzard Egberts <ed...@tantec.de> wrote:
>
> 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
Wieso (immer)?
>
> 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
Hint: es gibt Architekturen, wo "char" unsigned ist.
cu
Michael
0 new messages