Hallo, übersetzt man folgenden Code mit dem avr-gcc (ich benutze avr-gcc (GCC) 3.4.6) erhält man folgende Fehlermeldung: [pre] bash:/tmp$ avr-gcc test.c -Wall test.c:4: warning: left shift count >= width of type [/pre} Code: [c] #define _AVR_ATmega8_ 1 #include <stdint.h> uint32_t N=(1<<20); int main() { while(1); } [/c} Das ist ganz offensichtlich totaler Blödsinn, da 1<<20 locker in einen 32-Bit Datentyp passen würde. Leider ist es aber eben nicht nur eine Warnung -sondern der Typ wird tatsächlich auch falsch berechnet - weil nach dem 16. Bit abgeschnitten. Kann mir jemand diesen Fehler, vielleicht mit einem etwas neuerern Compiler, bestätigen? Danke, Martin L. PS: Warum gehen die Formatierungen nicht?
Martin L. wrote: > Kann mir jemand diesen Fehler, vielleicht mit einem etwas neuerern > Compiler, bestätigen? Ich kann dir bestätigen, dass dies kein Compilerfehler ist. Die Konstante 1 ist vom Typ "int", und da der nur 16 Bits umfasst ist 1<<20 ebenfalls vom Typ "int". Und damit 0. Der Compiler hat dich freundlicherweise auch darauf hingewiesen. Für die Auswahl des korrekten Datentyps bist du selbst verantwortlich. Also schreib 1L<<20.
Martin L. wrote:
> PS: Warum gehen die Formatierungen nicht?
Mit eckiger statt geschweifter Klammer geht es wohl schon.
Merke: Nicht an allem was nicht gleich funktioniert sind andere schuld. Nicht der Compiler und nicht der Webserver.
Andreas Kaiser wrote: > Martin L. wrote: > >> PS: Warum gehen die Formatierungen nicht? > > Mit eckiger statt geschweifter Klammer geht es wohl schon. Sind doch eckige Klammern [[[[ ]]]]]
Andreas Kaiser wrote: > Martin L. wrote: > >> Kann mir jemand diesen Fehler, vielleicht mit einem etwas neuerern >> Compiler, bestätigen? > > Ich kann dir bestätigen, dass dies kein Compilerfehler ist. > > Die Konstante 1 ist vom Typ "int", und da der nur 16 Bits umfasst ist > 1<<20 ebenfalls vom Typ "int". Und damit 0. Ah - ich verstehe. Der Compiler bezieht diese Fehlermeldung nicht auf den Zieldatentyp (N) sondern auf die Zwischenwerte die er erst nach der Berechnung auf den Zielwert castet. Ich dachte es wäre andersherum. Vielen Dank, Martin L.
Andreas Kaiser wrote:
> Diese beiden auch: [/c} ?
Ja - genauso eckig. Bin ich jetzt schwer von Begriff oder sind meine
eckigen Klammern andere als Deine?
Viele Grüße,
Martin L.
Martin L. wrote: > Andreas Kaiser wrote: >> Diese beiden auch: [/c} ? > > Ja - genauso eckig. Bin ich jetzt schwer von Begriff oder sind meine > eckigen Klammern andere als Deine? Du musst schon einen ziemlich merkwürdigen Zeichensatz verwenden, wenn bei dir [/c} und [/c] gleich aussehen.
OK - ich verstehe. Ich hatte mich bei den schließenden Klammern vertippt und bei mir sehen die geschweiften Klammern den Eckigen wirklich zum Verwechseln ähnlich ... also fast gleich ... Ist halt ein alter Röhrenmonitor... Danke
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.