WinAVR warum hier kein Warning?

"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.

--
cheers, J"org               .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/                        NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)

-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