Hallo, aufgrund einer Softwareneuparametrierung prüfe ich nun die vorhandene Rechenroutine mit den neuen Parametern auf Über-/Unterlauf. Nun habe ich folgende Frage : Was treibt der Compiler, wenn ein "signed long" Typ mit negativem Inhalt auf ein "unsigned long" gecastet wird ? Wie sieht dann das Ergbnis aus ? Bei der "ALT-LAST" die ich momentan bearbeite wurde das MINUS-Zeichen der "signed long" Variablen nicht berücksichtigt ! Ist dies o.k. , eher unschön oder schon kriminell ? Der Variableninhalt kann definitiv negativ werden.
Ich geh mal davon aus, dass du C sprichst. > Was treibt der Compiler, wenn ein "signed long" Typ mit > negativem Inhalt auf ein "unsigned long" Der Compiler vermerkt sich in seinen Unterlagen, dass der Datentyp jetzt nicht mehr 'signed' sondern 'unsigned' ist. Ansonsten passiert nichts. Soll heissen: das Bitmuster verändert sich nicht. > Der Variableninhalt kann definitiv > negativ werden. Wenn der Compiler Zweierkomplement Arithmetik benutzt (davon können wir mal ausgehen), dann wirst du da schöne große unsigned Zahlen sehen.
> Der Compiler vermerkt sich in seinen Unterlagen, dass der > Datentyp jetzt nicht mehr 'signed' sondern 'unsigned' ist. > Ansonsten passiert nichts. Soll heissen: das Bitmuster > verändert sich nicht. Auf gängigen Architekturen stimmt das, aber steht es auch im C-Standard, dass das Bitmuster gleichbleibt? Das Überlauf-Verhalten beim unsigned/signed-casten ist soweit ich weiß undefiniert, aber das ist nur meine Vermutung.
Ich seh schon, meine Frage war nicht ganz verkehrt. Es scheint nicht eindeutig zu sein was passiert. Daher werde ich es mal im C-Spy meiner IAR-Workbench (Renesas M16C) testen. Bin mal auf Ergebnis gespannt. Schon mal Danke für die Antworten.
Chris wrote: >> Der Compiler vermerkt sich in seinen Unterlagen, dass der >> Datentyp jetzt nicht mehr 'signed' sondern 'unsigned' ist. >> Ansonsten passiert nichts. Soll heissen: das Bitmuster >> verändert sich nicht. > > Auf gängigen Architekturen stimmt das, aber steht es auch im C-Standard, > dass das Bitmuster gleichbleibt? Wenn ich mich richtig erinnere, ist das Verhalten der meisten casts (alle?) sowieso 'implementation defined'. > Das Überlauf-Verhalten beim unsigned/signed-casten ist soweit ich weiß > undefiniert, aber das ist nur meine Vermutung. Ich denke du hast hier wohl recht. Daher auch meine Anmerkung oben von wegen '2-er Komplement'. Bei diesen Architekturen (und das ist ja wohl die Mayorität) ist das zumindest auf den Architekturen auf denen ich bisher war immer so gewesen.
Nur wenn der Zieltyp vorzeichenbehaftet ist, ist das Resultat undefiniert. Die Norm sagt zu Konvertierungen eines beliebigen Integertyps in einen vorzeichenlosen Integer, der für den Wert zu klein ist, folgendes: 2 Otherwise, if the new type is unsigned, the value is converted by repeatedly adding or subtracting one more than the maximum value that can be represented in the new type until the value is in the range of the new type.
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.