dieses ist total simpel, jedoch wird bei der IF bedingung immer der else
Zweig ausgeführt, obwohl das 8. Element 128 ist. Warum funktioniert das
nicht?
Rufus Τ. Firefly schrieb:> Johann L. schrieb:>> Einfach Warnungen beachten:>> Das ist aber ein ganz anderes Problem und hat nichts mit dem Array> oder dem Zugriff darauf zu tun.
Nö, Warnungen nicht zu beachten ist quasi immer ein Problem!
Ins Array wird nämlich keine 128 geschrieben, sondern eine -128. Mit
ein paar mehr Zeilen sind wie Warnungen:
1
<stdin>: In function 'main':
2
<stdin>:6:3: warning: overflow in implicit constant conversion [-Woverflow]
3
char element[] = { 1, 2, 4, 8, 16, 32, 65, 128 };
4
^
5
<stdin>:11:5: warning: comparison is always false due to limited range of data type [-Wtype-limits]
6
if (element[8]==128)
Die Korrektur besteht also zunächst mal darin, einen unsigned char (oder
uint8_t) für element[] zu verwenden. Danach werden die Warnmeldungen
zu:
1
<stdin>: In function 'main':
2
<stdin>:11:16: warning: array subscript is above array bounds [-Warray-bounds]
3
if (element[8]==128)
4
^
Jeder Warnung zeigt ein Problem auf und weist in Richtung der Lösung.
Nachdem alle Warnungen behoben sind, funktioniert zumindest dieser Teil
wie er soll.
Wie kommst du darauf, daß diese Warnungen auf ganz andere Probleme
zeigen?
Johann L. schrieb:> Wie kommst du darauf, daß diese Warnungen auf ganz andere Probleme> zeigen?
Du reitest auf dem im Array stehenden Wert herum, das ursprüngliche
Problem des Threadstarters aber lag in seinem fehlerhaften Arrayzugriff
über die Arraygrenzen hinaus.
Rufus Τ. Firefly schrieb:> Johann L. schrieb:>> Wie kommst du darauf, daß diese Warnungen auf ganz andere Probleme>> zeigen?>> Du reitest auf dem im Array stehenden Wert herum, das ursprüngliche> Problem des Threadstarters aber lag in seinem fehlerhaften Arrayzugriff> über die Arraygrenzen hinaus.
Nein, ich reite auf jeder Warnung herum, auch auf der, die auf den
Zugriff jenseits der Arraygrenzen hinweist.
Übrigens wird der der Zugriff elament[8]==128 idR wegoptimiert da der
Vergleich immer falsch ist (2. Warnung), der Zugriff stellt also
zunächst kein ein Problem dar, da er nie ausgeführt wird.
Peter K. schrieb:> Einmal eine ganz Blöde Frage: Das ist doch ein char-Array. Muss ein Char> nicht mit '' deklariert werden?
Nein. char blub[42] sagt erstmal nur ein Array aus 8-Bit-Zahlen, je nach
Compiler signed oder unsigned. Da kannst du ganz normal Zahlen von (wenn
unsigned) 0-255 reintun oder eben mit 'a', 'b', '0' usw. den ASCII-CODE
einzelner Buchstaben.
troll schrieb:> Peter K. schrieb:>> Einmal eine ganz Blöde Frage: Das ist doch ein char-Array. Muss ein Char>> nicht mit '' deklariert werden?>> Nein. char blub[42] sagt erstmal nur ein Array aus 8-Bit-Zahlen, je nach> Compiler signed oder unsigned. Da kannst du ganz normal Zahlen von (wenn> unsigned) 0-255 reintun oder eben mit 'a', 'b', '0' usw. den ASCII-CODE> einzelner Buchstaben.
Ok, ich bin auch kein C-Profi. Ist mir nur so beim ersten Blick
aufgefallen.
Peter K. schrieb:> troll schrieb:>> Peter K. schrieb:>>> Einmal eine ganz Blöde Frage: Das ist doch ein char-Array. Muss ein Char>>> nicht mit '' deklariert werden?>>>> Nein. char blub[42] sagt erstmal nur ein Array aus 8-Bit-Zahlen, je nach>> Compiler signed oder unsigned. Da kannst du ganz normal Zahlen von (wenn>> unsigned) 0-255 reintun oder eben mit 'a', 'b', '0' usw. den ASCII-CODE>> einzelner Buchstaben.>> Ok, ich bin auch kein C-Profi. Ist mir nur so beim ersten Blick> aufgefallen.
Prinzipiell ist char für den Compiler nur ein Integer-Typ wie die
anderen auch, mit der Ausnahme, daß er ohne [un]signed-Präfix nicht
zwingend mit Vorzeichen sein muß.
Aber obwohl der Compiler es zulässt, einem char direkt eine Zahl
zuzuweisen, ist es durchaus sinnvoll diesen Typ (also ohne signed oder
unsigned davor) nur für Zeichen zu verwenden.
