64bit Variable in 8x 8bit array schreiben

[Stefan (Gast)]

Hallo,

irgendwie stehe ich auf dem Schlauch...
Ich habe eine 64bit große Variable .
Die möchte ich nun in ein 8 byte großes Array schreiben.
Wie mache ich das am Besten?

Beispiel:

var_64_bit = irgendein riesengroßer wert;
array[0] = 1. 8 bits der variable also Bit0 bis Bit7 von "var_64_bit"
array[1] = 2. 8 bits der variable
array[2] = 3. 8 bits der variable
array[3] = 4. 8 bits der variable
array[4] = 5. 8 bits der variable
array[5] = 6. 8 bits der variable
array[6] = 7. 8 bits der variable
array[7] = 8. 8 bits der variable

Danke für die Hilfe.

Stefan

[dummschwaetzer (Gast)]

union

[Ingo L. (corrtexx)]

Stefan schrieb:
> Wie mache ich das am Besten?
Mit einer union

union{
 uint64_t GrosseVar;
 uint8_t Var[8];
}

[Yalu X. (yalu) (Moderator)]

Wenn es portabel sein soll, mit Shifts.

[Ingo L. (corrtexx)]

Yalu X. schrieb:
> Wenn es portabel sein soll, mit Shifts.
Wohl Dem, der einen Barrelshifter an Bord hat ;)

[pumuggl (Gast)]

Wenn es wirklich portabel sein soll, natuerlich mit Java.


LOL.

[A. F. (artur-f)]

Yalu X. schrieb:
> Wenn es portabel sein soll, mit Shifts.
Jo, ich würde es auch so machen.

 uint8_t array[8];
 uint64_t var_64_bit = 0xFFEEDDCCBBAA2211;
    
    for (char i = 0; i < 8; i++) {
      array[i] =  (uint8_t)(var_64_bit >> (i * 8));
    }

[pumuggl (Gast)]

Damit man genau solchen Krampf nicht mit shifts machen muss,
gibt es Unions. Falls auf einer der Zielarchitekturen die
Endianess nicht passt, muss man halt mal kurz umschalten.
Ernsthafte Compiler haben da Pragmas dafuer.

[Dirk B. (dirkb2)]

Ingo L. schrieb:
> Yalu X. schrieb:
>> Wenn es portabel sein soll, mit Shifts.
> Wohl Dem, der einen Barrelshifter an Bord hat ;)

Oder einen Compiler der optimieren darf und kann.
Dann wird Byte-weise zugegriffen und nicht geschoben.

[Dirk B. (dirkb2)]

pumuggl schrieb:
> Damit man genau solchen Krampf nicht mit shifts machen muss,
> gibt es Unions.

Dafür sind unions nicht gedacht.
Der Compiler kann das optimieren, wenn er darf.

[Ingo L. (corrtexx)]

>Wenn es portabel sein soll, mit Shifts.

uint64_t var_64_bit_dummy = 0;
var_64_bit_dummy  = var_64_bit;
for (uint8_t ByteNr = 0; ByteNr < 8; ByteNr++){
 Array[ByteNr] = (uint8_t)(var_64_bit_dummy & 0xff);
 var_64_bit_dummy /= 256;  
}

[Thomas W. (goaty)]

Geht das nicht ?

uint64_t var_64_bit = 0xFFEEDDCCBBAA2211;
*(uint64_t*)&array[0] = var_64_bit;

[pumuggl (Gast)]

Man koennte die inkriminierte Funktion in VHDL schreiben und dazulinken.

[Ingo L. (corrtexx)]

Thomas W. schrieb:
> uint64_t var_64_bit = 0xFFEEDDCCBBAA2211;
> *(uint64_t*)&array[0] = var_64_bit;
Das is aber schon mehr als "dirty".

[Dirk B. (dirkb2)]

Ingo L. schrieb:
> Thomas W. schrieb:
>> uint64_t var_64_bit = 0xFFEEDDCCBBAA2211;
>> *(uint64_t*)&array[0] = var_64_bit;
> Das is aber schon mehr als "dirty".

Das kann zum einen schief gehen, wenn das Alignement nicht passt,
desweiteren muß die Endianess nicht passen.

Darum Shift

[Yalu X. (yalu) (Moderator)]

Thomas W. schrieb:
> *(uint64_t*)&array[0] = var_64_bit;

Das verstößt gegen die "strict aliasing rule", die da lautet:

An object shall have its stored value accessed only by an lvalue
expression that has one of the following types:

- a type compatible with the effective type of the object,

- a qualified version of a type compatible with the effective type of the
  object,

- a type that is the signed or unsigned type corresponding to the
  effective type of the object,

- a type that is the signed or unsigned type corresponding to a qualified
  version of the effective type of the object,

- an aggregate or union type that includes one of the aforementioned
  types among its members (including, recursively, a member of a
  subaggregate or contained union), or

- a character type.

(Quelle: ISO/IEC 9899:2017 Programming Languages — C, N2176)

[Wilhelm M. (wimalopaan)]

pumuggl schrieb:
> Damit man genau solchen Krampf nicht mit shifts machen muss,
> gibt es Unions

Ich kann dem originalen Post des TO nicht entnehmen, ob es C oder C++ 
sein soll. Bei C++ geht es mit unions so auf keinen Fall, denn man 
müsste dort das active-member der union explizit ändern (oder gleich 
std::variant benutzen).

[Wilhelm M. (wimalopaan)]

pumuggl schrieb:
> Damit man genau solchen Krampf nicht mit shifts machen muss

Shifts sind der einzig in allen Fällen korrekte Weg es zu machen.

[Thomas W. (goaty)]

Oder vielleicht:

uint64_t a = 0x1234567812345678;
char b[8];
*reinterpret_cast<uint64_t*>(&b[0]) = a;

Ich schau mal was noch schmutziger geht ;-)

[Dirk B. (dirkb2)]

Thomas W. schrieb:
> Oder vielleicht:
>
> uint64_t a = 0x1234567812345678;
> char b[8];
> *reinterpret_cast<uint64_t*>(&b[0]) = a;
>
> Ich schau mal was noch schmutziger geht ;-)

Da bleibt immer noch das Problem mit der Endianess.

[Thomas W. (goaty)]

uint64_t a = 0x1234567812345678;
char b[8];
a = __builtin_bswap64(a);
*reinterpret_cast<uint64_t*>(&b[0]) = a;

[Nop (Gast)]

Oder man nimmt ganz einfach memcpy.

[Dirk B. (dirkb2)]

Nop schrieb:
> Oder man nimmt ganz einfach memcpy.

Da bleibt immer noch das Problem mit der Endianess.

[Nop (Gast)]

Dirk B. schrieb:
> Nop schrieb:
>> Oder man nimmt ganz einfach memcpy.
>
> Da bleibt immer noch das Problem mit der Endianess.

Dazu kann man Macros wie HostToNetwork oder so nehmen, also wenn man es 
überhaupt portabel braucht.

[Dirk B. (dirkb2)]

Nop schrieb:
> Dazu kann man Macros wie HostToNetwork oder so nehmen, also wenn man es
> überhaupt portabel braucht.

Die wandelt in Big-Endian um.

Du müsstest also schon beim schreiben wissen, welche Endianess das 
System hat.
Das fällt beim shiften weg.

[Jemand (Gast)]

Thomas W. schrieb:
> Oder vielleicht:
>
> uint64_t a = 0x1234567812345678;
> char b[8];
> *reinterpret_cast<uint64_t*>(&b[0]) = a;
>
> Ich schau mal was noch schmutziger geht ;-)

Lass die Finger von Konstrukten, die du nicht verstehst.

[Rolf M. (rmagnus)]

pumuggl schrieb:
> Damit man genau solchen Krampf nicht mit shifts machen muss,
> gibt es Unions.

Nein. Sie wurden zwar so oft dafür missbraucht, dass das in C irgendwann 
mal auch erlaubt wurde, aber gedacht waren sie dafür nicht.

> Falls auf einer der Zielarchitekturen die Endianess nicht passt, muss man
> halt mal kurz umschalten.
> Ernsthafte Compiler haben da Pragmas dafuer.

Ernsthafte Programmierer nutzen keine proprietären 
Compiler-Erweiterungen für etwas, das auch portabel geht.

[Bernd K. (prof7bit)]

Dirk B. schrieb:
> Dafür sind unions nicht gedacht.
> Der Compiler kann das optimieren, wenn er darf.

Es kommt auf die Sprache an, in C ist type punning mit unions explizit 
erlaubt, in C++ nicht.

[c-hater (Gast)]

Yalu X. schrieb:

> Das verstößt gegen die "strict aliasing rule", die da lautet:
[...]

Und wieder mal die Bibel zitiert...

Es gibt auch Andersgläubige, für die die C-Bibel soviel wert ist wie ein 
trockener Furz im Seewind.

Davon mal abgesehen: der TO hat sich weder auf eine Sprache festgelegt 
noch hat er spezifiziert, dass er die Einzelbytes in dem Array in einer 
bestimmten Reihenfolge haben möchte.

Damit ist sowieso alles offen und jede, wirklich jede Lösung richtig, 
sofern sie nur die 64Bit irgendwie in 8Bytes zerlegt...

C ist dafür sowieso vollkommen ungeeignet, weil in dieser Dreckssprache 
Bytes überhaupt nicht existieren, jedenfalls nicht in der Form, wie sie 
heutzutage jeder geistig Normale versteht, nämlich als Ansammlung von 
8Bits...

[Nop (Gast)]

c-hater schrieb:

> Es gibt auch Andersgläubige, für die die C-Bibel soviel wert ist wie ein
> trockener Furz im Seewind.

Die programmieren dann kein C und wundern sich, wenn ihr kaputter Code 
auf einmal zerbricht.

> C ist dafür sowieso vollkommen ungeeignet, weil in dieser Dreckssprache
> Bytes überhaupt nicht existieren, jedenfalls nicht in der Form, wie sie
> heutzutage jeder geistig Normale versteht, nämlich als Ansammlung von
> 8Bits...

Was genau glaubst Du eigentlich, wofür "uint8_t" steht? Seit ZWEI 
JAHRZEHNTEN?

[Johann L. (gjlayde)]

c-hater schrieb:
> wie ein trockener Furz im Seewind.

Da bist du ja der absolute Experte, ganz ohne Zweifel.

[Ingo Less (Gast)]

Wer glaubt, dass nur weil er c-hater heisst, er kein c kann irrt 
gewaltig...

[c-hater (Gast)]

Nop schrieb:

> Was genau glaubst Du eigentlich, wofür "uint8_t" steht? Seit ZWEI
> JAHRZEHNTEN?

Und wo genau kam uint8_t im OT vor? Der Mann will Bytes. Und in 
praktisch jeder Sprache außer C/C++ kann er Bytes bekommen...

[Bernd K. (prof7bit)]

c-hater schrieb:
> Nop schrieb:
>
>> Was genau glaubst Du eigentlich, wofür "uint8_t" steht? Seit ZWEI
>> JAHRZEHNTEN?
>
> Und wo genau kam uint8_t im OT vor? Der Mann will Bytes. Und in
> praktisch jeder Sprache außer C/C++ kann er Bytes bekommen...

Jetzt machst Du Dich lächerlich. Manchmal kann man zwar noch schmunzeln 
wenn Du wieder mal so nen wortgewaltigen Ausbruch wie oben hast, aber 
das jetzt war irgendwie völliger Käse.

[c-hater (Gast)]

Bernd K. schrieb:

> aber
> das jetzt war irgendwie völliger Käse.

Du hast die Bibel also nicht gelesen. Das kostet zehn Ave Richie. 
Mindestens.

[Heiko L. (zer0)]

Nop schrieb:
> Was genau glaubst Du eigentlich, wofür "uint8_t" steht? Seit ZWEI
> JAHRZEHNTEN?

Für eine Zahl <256.

Since the standard does not require uint8_t to be a character type, you could imagine a compiler vendor deliberately making it a separate type to be able to take advantage of the strict aliasing rule.

https://gist.github.com/jibsen/da6be27cde4d526ee564

[Nop (Gast)]

Heiko L. schrieb:

> Für eine Zahl <256.

Mit 8 bit, was man als Byte bezeichnet. Auf Systemen, wo ein Byte nicht 
8 Bit hätte, gäbe es diesen Datentyp deswegen nicht. Der Rest des 
Artikels dreht sich lediglich darum, daß die Aliasing-Regeln für uint8_t 
nicht wie für char gelten, was aber auch nicht notwendig ist.

[Rolf M. (rmagnus)]

c-hater schrieb:
> Es gibt auch Andersgläubige, für die die C-Bibel soviel wert ist wie ein
> trockener Furz im Seewind.

Ein internationaler ISO-Standard ist keine Bibel, und programmieren hat 
nicht viel mit glauben zu tun, sondern damit, eine Spezifikation zu 
verstehen und korrekt anzuwenden. Wer sich dazu entschließt, was anderes 
zu "glauben" als das, was in der Spezifikation steht, wird natürlich 
auch nichts auf die Reihe bekommen.

[Heiko L. (zer0)]

Nop schrieb:
> Heiko L. schrieb:
>
>> Für eine Zahl <256.
>
> Mit 8 bit, was man als Byte bezeichnet. Auf Systemen, wo ein Byte nicht
> 8 Bit hätte, gäbe es diesen Datentyp deswegen nicht. Der Rest des
> Artikels dreht sich lediglich darum, daß die Aliasing-Regeln für uint8_t
> nicht wie für char gelten, was aber auch nicht notwendig ist.

Wenn man nicht uint8_t* nimmt, um einfach im Speicher rumzulesen schon. 
:)

[Heiko L. (zer0)]

Rolf M. schrieb:
> c-hater schrieb:
>> Es gibt auch Andersgläubige, für die die C-Bibel soviel wert ist wie ein
>> trockener Furz im Seewind.
>
> Ein internationaler ISO-Standard ist keine Bibel, und programmieren hat
> nicht viel mit glauben zu tun, sondern damit, eine Spezifikation zu
> verstehen und korrekt anzuwenden.

Je nachdem, ob das Komittee dann noch ein paar Definitionen nachreicht, 
oder entschließt, eine Definitionslücke für Optimierungen zu 
verwenden...

[Nop (Gast)]

Heiko L. schrieb:

> Wenn man nicht uint8_t* nimmt, um einfach im Speicher rumzulesen schon.
> :)

Das sollte man nicht tun. Wäre ja auch nicht sinnvoll, wenn uint8_t 
alles aliasen würde, weil das dann numerische Berechnungen verlangsamen 
könnte.

Für sowas nimmt man char* und stellt im Sinne der Portabilität erstmal 
sicher, daß das überhaupt 8 bit sind. Byteweises Lesen ergibt 
schließlich nur Sinn auf Architekturen, wo es überhaupt Bytes gibt (was 
allerdings heute der Normalfall ist). Aber C kann man eben auch auf CPUs 
loslassen, die anders aufgebaut sind.

[Rolf M. (rmagnus)]

Nop schrieb:
> Byteweises Lesen ergibt
> schließlich nur Sinn auf Architekturen, wo es überhaupt Bytes gibt (was
> allerdings heute der Normalfall ist).

Bytes gibt es überall. Sie sind nur nicht zwingend 8 Bit breit. Und 
nein, das ist keine C-Spezialität.

[Heiko L. (zer0)]

Nop schrieb:
> Das sollte man nicht tun. Wäre ja auch nicht sinnvoll, wenn uint8_t
> alles aliasen würde, weil das dann numerische Berechnungen verlangsamen
> könnte.

Naja, den typedef kann man schnell nachlesen. Das ist eben der Punkt. 
C!=C.

[Carl D. (jcw2)]

c-hater schrieb:
> Nop schrieb:
>
>> Was genau glaubst Du eigentlich, wofür "uint8_t" steht? Seit ZWEI
>> JAHRZEHNTEN?
>
> Und wo genau kam uint8_t im OT vor? Der Mann will Bytes. Und in
> praktisch jeder Sprache außer C/C++ kann er Bytes bekommen...

Echt, in C++17 muß er noch std:: vor das byte schreiben.

[Peter D. (peda)]

Ingo Less schrieb:
> Wer glaubt, dass nur weil er c-hater heisst, er kein c kann irrt
> gewaltig...

Wer glaubt, daß er C kann, nur weil er die Syntax kennt, irrt auch 
gewaltig.

[Stefan (Gast)]

Hallo...
Erstmal vielen Dank dafür...

Ich habe es jetzt so gemacht:

uint8_t array[8];
 uint64_t var_64_bit = 0xFFEEDDCCBBAA2211;
    
    for (char i = 0; i < 8; i++) {
      array[i] =  (uint8_t)(var_64_bit >> (i * 8));
    }

Das läuft prima...
Vielen Dank dafür.

Wollte jetzt hier keine Grundsatzdiskussion vom Zaun brechen.