Forum: Compiler & IDEs uint32_t var=1<<15; //ergibt 0xFFFF8000 ?!?!


von Frank N. (betafrank)


Lesenswert?

Hallo Leute, ich steh grad auf dem Schlauch.

Unter WinAVR 3.4.5

wird 1<<15 zu 0xFFFF8000.

Gibts ein WorkAround (außer aufsplitten auf 4 einzelne Bytes;-)? Gibts 
noch andere Fallen mit 32-Bit? Bekannt wird es ja wohl sein?!

Gruß Frank

von Karl H. (kbuchegg)


Lesenswert?

Frank N. wrote:
> Hallo Leute, ich steh grad auf dem Schlauch.
>
> Unter WinAVR 3.4.5
>
> wird 1<<15 zu 0xFFFF8000.
>

Ja das ist auch richtig so :-)

Wie kommts?

1 ist ein int. 15 ist ebenfalls ein int.
Daher wird die ganze Operation 1 << 15 im Zahlenraum
int ausgeführt und ergibt  0x8000
Der Datentyp dafür ist natürlich ebenfalls int.

Da du aber ein long Ergebnis angegeben hast, gehe ich
mal davon aus, dass du diese 0x8000 an einen long
zugewiesen hast. Dabei muss der int natürlich auf einen
long erweitert werden. Das geschieht selbstverständlich
unter Berücksichtigung des Vorzeichens. Und da 0x8000
eine negative Zahl ist, lautet die identische negative
Zahl in long 0xFFFF8000

> Gibts ein WorkAround?

Aber sicher doch.
Du musst nur dafür sorgen, dass der Compiler von vorne herein
alles in long, bzw. unsigned long sieht. Und schon ist dein
Problem vom Tisch:

   1UL << 15

von Frank N. (betafrank)


Lesenswert?

Ja und schon geht es...
Danke Karl Heinz - für's Augen öffnen und Lösung finden :-)

von Karl H. (kbuchegg)


Lesenswert?

Laufzeitmässig könnte es allerdings besser sein, die Schiebeoperation
in int machen zu lassen und vor der Erweiterung auf long das
Vorzeichen mit einem cast auf unsigned zu unterdrücken

    (unsigned int)(1<<15)

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
Noch kein Account? Hier anmelden.