Gast
#1684459
Ich versuch's so:
1 | |
2 | |
3 | |
4 | |
Da kommt leider Müll raus. Liegt hier ein systematischer Fehler vor?
|
Anzeige
|
int32_t in Bytes zerlegen
Gast
#1684459
Ich versuch's so:
Da kommt leider Müll raus. Liegt hier ein systematischer Fehler vor? Mehrere Fehler auf einmal:
a) mangelnder Quelltext
b) miese Fehlerbeschreibung
c) kein vorheriger Versuch, das Problem selbst zu
lösen - ca. einmal pro Tag darf sich hier jemand die
Mühe machen und jemandem sagen, daß man a) mit
unvollständigen Quelltexten nichts anfangen kann,
und b) ohne ordentliche Fehlerbeschreibung nicht helfen
kann ("es geht nicht, sagt mir warum"), und c) erst
mal die 156742 Threads lesen kann, in denen beschrieben
wird, wie man Variablen in Byte splitten kann und
umgekehrt und in denen steht, daß man a)...
so eventuell
typedef union _INT32_VAL
{
char Buffer[4];
INT32 IntWert;
} INT32_VAL;
Das macht aber nicht das selbe wie im 1. posting ... sollte es dass?
>>>>> int32_t in Bytes zerlegen
Na ja, es ist schwer, allgemein zu sagen, was das erste Posting macht,
denn da es einen signed Typ verwendet, ist das Ergebnis
compilerabhängig. Sagen wir mal so: Es kann sein, dass die Union
dasselbe macht wie das erste Posting, muss aber nicht.
> Das macht aber nicht das selbe wie im 1. posting ...
So allgemein ist das nicht richtig.
Wenn du den Trick mit der Union machst, fällst du bei Wechsel der Endianness auf die Schnauze, und das ist noch nicht mal compilerabhängig :-) ne fällst du nicht weil hier nur zerlegt wird und nicht interpretiert !!! Du musst schon wissen was die bytes bedeuten ob float,int etc.. Buffer[0] enthält bei Big/Little Endian das selbe ... ojemine ... ja genau 1 byte :-) Du programmierst unter Windows, oder? nee Du programmierst gar nicht? wie kommst zu der Annahme? Abgesehen davon ist Endianess sowas von typisch compilerabhängiger Eigenschaft (dass der sie wiederum von der Prozessorarchitektur ableitet, ist ein anderes Thema (und es gibt auch gemischte Architekturen)).
Gast
#1684575
wanda schrieb: > Ich versuch's so: > char3 = int32>>24; > char2 = int32>>16; > char1 = int32>>8; > char0 = int32; > > Da kommt leider Müll raus. Liegt hier ein systematischer Fehler vor? Ja. > Abgesehen davon ist Endianess sowas von typisch compilerabhängiger > Eigenschaft (dass der sie wiederum von der Prozessorarchitektur > ableitet, ist ein anderes Thema (und es gibt auch gemischte > Architekturen)). Aha. Wenn du in Assembler programmierst hast du also keine Endianess mehr, oder doch, oder was genau jetzt?
Gast
#1684939
Den Tipp mit der union hatte ich auch ausprobiert, bis auf die Problematik der endianess sollten beide Methoden dasselbe Ergebnis haben. Der Fehler (Muell) wird also an anderer Stelle verursacht . Danke. das glaub ich weniger ..... Ooooch. Glaub ich sofort. Antwort schreibenBitte melde dich an, um einen Beitrag zu schreiben. |
Anzeige
|