Typenwandlung uint zu uchar[2]

Vor allem gibt es welche, die richtig sind.

Entweder mit union oder mit Zeiegrn udn ein paar casts.

Dieses Forum ist ziemlich voll von sehr ähnlichen Fällen.

Warum?
Es kommt drauf an, was er will und wie man mit union arbeitet.

Auf jeden Fall hast du insofern recht, als es nicht mit Union geht, 
sondern bestenfalls mit union :-)

Martin schrieb:
> Weil dein Vorschlag beinhaltet, in die eine Variante der Union zu
> schreiben und aus der anderen zu lesen.
>
> Und das ist undefined behaviour, auch wenn die meisten Leute das einfach
> nicht einsehen wollen.

Dem Gesetz nach hast du Recht.

Allerdings greift hier die normative Kraft des Faktischen.
Besagtes Konstrukt wird seit Anbeginn der C-Welt so benutzt. Jeder 
Compilerbauer würde sich ins eigene Knie schiessen, wenn er hier 
absichtlich einen Problemkreis aufmacht. Denn: die für den Compilerbauer 
einfachste Variante ist es, wenn genau dieses Konstrukt (als 
Nebeneffekt) funktioniert.

Selbst die Jungs in comp.lang.std.c-c++ (und da hängen immerhin 
diejenigen rum, die den Standard machen), haben längst aufgegeben dieses 
Konstrukt als Fehler zu werten. Sie machen eine Fussnote, dass es 
eigentlich nicht ganz korrekt ist, aber sie machen da schon seit Jahren 
kein Drama mehr draus. Bzw. wenn ich so zurückdenke, haben sie da nie 
ein Drama draus gemacht.

undefiniert ist es deshalb, weil man zb mit einer union aus double und 
einem unsigned char Array eben nicht garantieren kann, dass jede 
Bytefolge, die ich da reinschreibe auch zu einem gültigen double führt. 
Aus diesem und ähnlichen Gründen kann diese Benutzung einer union nicht 
legalisiert werden.

Martin schrieb:
> Und das ist undefined behaviour, auch wenn die meisten Leute das einfach
> nicht einsehen wollen.

Die Annahme, daß man solche Fummeleien immer portabel haben müsste, ist 
ebenso verbreitet.
Viele wollen nicht einsehen, daß ein Programm für einen MC ohnehin nur 
sehr bedingt portabel ist.
Also geht es ggf. nicht darum, was der C-Standard sagt, sondern wie es 
auf dem vorhandenen System aussieht. Und damit geht es nicht mehr um 
eine undefined beh. von ISO-C, sondern um ein sehr definiertes Verhalten 
des gcc oder was auch immer.

Ich bin ja auch ein Freund von Standards und portablen Programmen, aber 
wenn man beschließt, auf die Bytes einer int zuzugreifen, dann ist es eh 
Essig mit C-Standard und der Hinweis darauf für die Katz'.
"nicht richtig" wird damit zu einer eher subjektiven Aussage, die für 
sich genommen nicht viel hilft. Sinnvoller wäre höchstens der Hinweis, 
daß es damit nicht mehr portabel ist.

Ist natürlich nur meine Meinung.

Martin schrieb:
> Und Substantive werden im Deutschen übrigens groß geschrieben.

In C aber nicht. :-)

Martin schrieb:
> Karl Heinz Buchegger schrieb:
>> Dem Gesetz nach hast du Recht.
>>
>> Allerdings greift hier die normative Kraft des Faktischen.
>
> Mag ja alles sein, aber gerade auch hier im Forum hat sich so eine
> "Scheißegal, wir fummeln es solange hin, bis die LED blinkt"-Mentalität
> festgesetzt.

Geb ich dir recht.
Aber in diesem konkreten speziellen Fall bellst du den falschen Baum 
hinauf.

Heinz schrieb:
>>Wenn man weiß, was C garantiert und was nicht, kann man sich die ein
>>oder andere Freiheit erlauben.
>
> Wo ist denn dann da die Freiheit? Wenn man genau das macht was
> garantiert ist nimmt man sich / erlaubt man sich keinerlei Freiheit.
>
>>aber gerade auch hier im Forum hat sich so eine "Scheißegal, wir fummeln es
>>solange hin, bis die LED blinkt"-Mentalität festgesetzt.
>
> Dem kann ich so nicht zustimmen. Gerade hier und hier vor allem Falk,
> Karl Heinz und Lothar sind diejenigen die hier immer wieder auf formal
> unkorrekte bzw. bedenkliche sprachliche Konstrukte hinweisen.

@Martin.

Damit das aber nicht in den falschen Hals kommt.
Ich (und sicher auch die anderen) würden uns freuen, wenn wir einen 
weiteren Mitstreiter zum Thema "gutes und standardkonformes C" bekommen. 
Denn in einem Punkt hast du natürlich recht: Es ist schon abenteuerlich, 
welches noch nicht mal Viertelwissen hier im Forum immer wieder 
durchkommt. Wenn wir es schaffen, dass die Promotionregeln einigermassen 
sitzen, dann ist vielerorts schon einiges erreicht.

Rolf Magnus schrieb:
> Klaus Wachtler schrieb:
>> Also geht es ggf. nicht darum, was der C-Standard sagt, sondern wie es
>> auf dem vorhandenen System aussieht.
>
> Es gibt in C den vorgesehenen Weg, und es gibt den Weg über unions. Nur
> weil die auf dem vorhandenen System auch funktionieren, muß ich die doch
> nicht unbedingt dafür einsetzen.

Nein, muß man nicht.

>
>> Ich bin ja auch ein Freund von Standards und portablen Programmen, aber
>> wenn man beschließt, auf die Bytes einer int zuzugreifen, dann ist es eh
>> Essig mit C-Standard und der Hinweis darauf für die Katz'.
>
> Deshalb muß man ja nicht gleich komplett alles über Bord werfen.

Nein, muß man nicht.

Ich habe nie behauptet, daß unions generell besser sind für einen 
solchen Fall.
Sie sind aber eine Möglichkeit (neben shiften und unions gibt es noch 
mehr).

Aber alle Methoden haben Vor- und Nachteile, und ich will nur behaupten, 
daß Portabilität auf einem MC nicht unbedingt das alleinige Kriterium 
ist.
Wenn man damit auf einem AVR umständliches Shiften umgehen kann, KANN es 
mit union sinnvoller sein.

Deshalb finde ich so eine pauschale (Nicht-) Aussage:
Martin schrieb:
> Mit Union ist es jedenfalls schonmal nicht richtig.
vollkommen überflüssig (vorsichtig formuliert).
Nur weil man mal (weitgehend zu Recht) gelernt hat, daß portabel und 
standardkonform toll ist, zeugt es nicht von Intelligenz, das gleich als 
Totschlagargument zu mißbrauchen, ohne je darüber nachgedacht zu haben.
Reflexe aus dem Rückenmark sind meistens schlecht beim Programmieren, 
mehr sehe ich nicht in diesem Beitrag.

Rolf Magnus schrieb:
> Ja, um eben diesem Trend entgegenzuwirken.

Den unterstütze ich auch ausdrücklich. Dann aber bitte mit dem richtigen 
Hinweis, daß es eben nicht portabel ist, und nicht mit dem
Blödsinn, daß es nicht ginge - ohne jede Begründung, wie man sich zu dem 
Quark verstiegen hat.


Ganz abgesehen davon, daß so eine Diskussion schon zigfach durchgekaut 
wurde und wohl nie enden wird, weil immer wieder jemand sich weigert, 
mal die bisherigen Threads dazu zu suchen, und neben den sinnvollen 
Aussagen dazu auch genauso regelmäßig der Unfug hervorgewürgt wird.

Klaus Wachtler schrieb:

> Aber alle Methoden haben Vor- und Nachteile,

Wenn wir mal von int und long weg verallgemeinern, also auch double in 
den Problemkreis mit hineinziehen, gibt es keinen standardkonformen Weg, 
um auf die einzelnen Bytes eines Datentyps zuzugreifen. Das ist nun mal 
so. Auch Pointer umcasten ist kein gültiger Weg.

Daher sind unions genauso gut oder schlecht wie alles andere.

Für int/long bleibt natürlich noch die Möglichkeit von Division zur 
Zerlegung und Multiplikation zum Zusammensetzen. Bei float/double geht 
das aber nicht.