Typ-Konvertierung

gast Gast #613435
Lesenswert?
• ▲
▼ 
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.
Antwort Zitieren Bearbeiten Thread verschieben Thread sperren Anmeldepflicht aktivieren Anpinnen Thread löschen Thread mit anderem zusammenführen Beitrag melden
Karl H. #613487
Lesenswert?
• ▲
▼ 
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.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Chris Gast #613651
Lesenswert?
• ▲
▼ 
> 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.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
gast Gast #613661
Lesenswert?
• ▲
▼ 
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.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Karl H. #613702
Lesenswert?
• ▲
▼ 
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.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Rolf Magnus Gast #613860
Lesenswert?
• ▲
▼ 
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.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Thread beobachten

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

Bestehender Account

oder

Mit Google-Account einloggen

Noch kein Account?

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren