Hallo alle zusammen,
uint8_t i8 = 0; uint16_t i16 = 0; uint32_t i32 = 20000;
i16=i32; i8=i32;
warum erzeugen die unteren 2 Zeilen eigentlich kein Warning in WinAVR obwohl ich den Parameter "-Wall" im gcc gesetzt habe?
Wo ist mein Denkfehler?
danke im voraus Werner
"Werner Brennecke" schrieb:
Hat nichts mit "WinAVR" zu tun, ist eine generische GCC-Frage. Musst du vermutlich auf der Entwicklerliste von GCC fragen, um eine kompetente Antwort zu erhalten, schließlich willst du ja von den GCC-Entwicklern wissen, was sie warum genau so implementiert haben, wie es implementiert ist.
-pedantic ;-) Spass beiseite! Muss halt kein Fehler sein denke ich mal, auch wenn sicher nicht gerne gesehn weil so u.U. nicht portabel. In Unkenntnis Deiner Tools oder Hardware ist der Themenkreis prinzipiell umfangreich:
- explizite/implizite Typumwandlung
- little/big endian
- unsigned int short fuer 16 Bit, sonst plattformabh. usw. usf.
Am wahrscheinlichsten sag ich mal sind dann in i8 einfach die low nibbles von i32 zu finden. But who knows? Auch wenns im Moment so funktioniert formuliere es wenigstens noch eindeutiger per typecast damit man spaeter noch liest dass Du weist was Du tust. Ev. macht dann auch ein anderer compi keinen Fehler weil er gleich erkennen kann was gemeint ist.
empfehle faq von der NG comp.lang.c
mfg Charlie
Moin,
Werner Brennecke schrieb...
ohl
Keine Ahnung, nutze den GCC nicht. Allerdings sind Warnungen ja auch nur=20 'kann', aber nicht 'mu=DF'.
=20
Keiner, denn solche Zuweisungen k=F6nnen immer mit Genauigkeitsverlust=20 einhergehen. Allerdings gibt es f=FCr den 'unsigned'-Fall eine klare=20 Reglung im Standard bez=FCglich Konversion:
1 When a value with integer type is converted to another=20 integer type other than _Bool, if the value can be=20 represented by the new type, it is unchanged. =20 2 Otherwise, if the new type is unsigned, the value is=20 converted by repeatedly adding or subtracting one more than the maximum value that can be represented in the=20 new type until the value is in the range of the new type.Nach Fall 2 wird der Code jetzt so interpretiert, wenn=20 sizeof(i8) =3D=3D sizeof(unsigned char) und sizeof(i16) =3D=3D sizeof(unsigned short) gilt:
i16=3Di32 % (USHRT_MAX+1); i8=3Di32 % (UCHAR_MAX+1);
- Heinz
Moin,
Karl M. Prager schrieb...
Ist schon portabel und vom Standard wohldefiniert, da es sich um=20 'unsigned' Typen handelt. Nur bei 'signed' Typen ist das Resultat 'implementation defined'.=20
Es ist eine implizite Umwandlung (kein cast vorhanden)
St=F6rt hier nicht, da unsigned wohldefiniert konvertiert wird.
Ack
Der Standard, und der sagt, da=DF es wohldefiniert ist, trotz m=F6glichem= =20 Genauigkeitsverlust.
Der Typecast wird auch nichts anderes machen k=F6nnen als bei der=20 impliziten Konversion passiert. Einzig f=FCr den Leser des Codes k=F6nnte e= s=20 ein Hinweis sein, da=DF an der entsprechenden Stelle ganz bewu=DFt an einen= =20 kleineren Datentyp zugewiesen wird.
=20
Ack
- Heinz
Have something to add? Share your thoughts — no account required.
Ask the community — no account required