Fehler im avr-gcc beim Berechnen von Konstanten

[Martin L. (Gast)]

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?

[Andreas K. (a-k)]

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.

[Andreas K. (a-k)]

Martin L. wrote:

> PS: Warum gehen die Formatierungen nicht?

Mit eckiger statt geschweifter Klammer geht es wohl schon.

[Andreas K. (a-k)]

Merke: Nicht an allem was nicht gleich funktioniert sind andere schuld. 
Nicht der Compiler und nicht der Webserver.

[Martin L. (Gast)]

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 K. (a-k)]

Diese beiden auch: [/c} ?

[Martin L. (Gast)]

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.

[Martin L. (Gast)]

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.

[Andreas K. (a-k)]

Sowohl als auch.

[Stefan E. (sternst)]

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.

[Martin L. (Gast)]

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