c - 2x unsigned char to int16_t

[conf (Gast)]

Hallo,

ich bekomme zwei Bytes die einen int16_t repräsentieren als unsigend 
char (high und low.)
Wie bekomme ich die Daten bit-weise (also ohne unsigend to signed 
conversation) in den int16_t?

int16_t data;
unsigned char high, low;

....

// Ohne Cast
// 8 bit high nach << = 0? 
data = low + (high << 8); 

// Mit Cast zu signed
// Data korruption durch cast? 
data = (int16_t)low + ( (int16_t)high << 8);

// Mit cast to unsigend 
// Data korruption durh impliziten cast, unsigend to sigend? 
data = (uint16_t)low + ( (uint16_t)high << 8);

Wie macht man es richtig?

[Daniel S. (daniel_s49)]

Einentlich brauchst du da nicht casten und persönlich benutze ich da 
immer das OR:

data = low | (high << 8);

[Peter II (Gast)]

conf schrieb:
> Wie bekomme ich die Daten bit-weise (also ohne unsigend to signed
> conversation) in den int16_t?

im Zweifelsfall so

int16_t data;
unsigned char high, low;

char* tmp = (char*)&data;
memcpy( tmp, high );
memcpy( tmp+1, low );

[Peter II (Gast)]

Daniel S. schrieb:
> Einentlich brauchst du da nicht casten und persönlich benutze ich da
> immer das OR:data = low | (high << 8);

da bin ich mir nicht sicher. Wenn low und high char sind und char signed 
ist, kommt da Unsinn raus.

Denn das low wird auf int erweitert und dann ist das höchste bit gesetzt 
wenn es low negativ war.

[Peter II (Gast)]

Peter II schrieb:
> da bin ich mir nicht sicher. Wenn low und high char sind und char signed
> ist, kommt da Unsinn raus.

ok, er hat ja unsigned char geschrieben. dann müsste es gehen.

[Curby23523 N. (Gast)]

Peter II schrieb:
> conf schrieb:
>> Wie bekomme ich die Daten bit-weise (also ohne unsigend to signed
>> conversation) in den int16_t?
>
> im Zweifelsfall so
>
>

> int16_t data;
> unsigned char high, low;
> 
> char* tmp = (char*)&data;
> memcpy( tmp, high );
> memcpy( tmp+1, low );
>

mempcy?? ok vermutlich macht ein kluger compiler alles richtig ich würde 
das aber anders machen:

uint16_t * tmp = (uint16_t *)&variable;
*tmp++ = low;
*tmp = high;

Oder gleich ein union nehmen:

union{
  uint8_t _Byte[2];
  uint16_t _Word;
} tmp;

tmp._Byte[0] = low;
tmp._Byte[1] = high;

[Peter II (Gast)]

Nils H. schrieb:
> mempcy?? ok vermutlich macht ein kluger compiler alles richtig ich würde
> das aber anders machen:
> uint16_t * tmp = (uint16_t *)&variable;
> *tmp++ = low;
> *tmp = high;

das kann nicht funktionieren. du meinst vermutlich uint8_t

[Curby23523 N. (Gast)]

Ja natürlich, danach dann als uint16_t * interpretieren.

[Dr. Sommer (Gast)]

Nicht schon wieder dieses Thema... Kurzfassung:

Daniel S. schrieb:
> immer das OR:data = low | (high << 8);
ist korrekt, falls deine Plattform 2er-Komplement nutzt (tun fast alle).

Peter II schrieb:
> im Zweifelsfall so
und
Nils H. schrieb:
> Oder gleich ein union nehmen:

Sind "falsch" und plattform-abhängig, funktioniert nur auf Little-Endian 
Prozessoren.

Nils H. schrieb:
> uint8_t _Byte[2];
>   uint16_t _Word;
Solche Bezeichner sind verboten und für die Standard-Library reserviert 
(alles was __ am Anfang/Ende enthält oder mit _ + Großbuchstabe 
beginnt).

conf schrieb:
> // Data korruption durh impliziten cast, unsigend to sigend?
Implizite Casts gibt es nicht. Casts sind immer explizit, 
Konvertierungen immer implizit.

[conf (Gast)]

Vielen Dank für die Unterstützung.

ich denke ich werd aufgrund der Lesbarkeit den Union verwenden.

Danke!

[conf (Gast)]

Dr. Sommer schrieb:
>> // Data korruption durh impliziten cast, unsigend to sigend?
> Implizite Casts gibt es nicht. Casts sind immer explizit,
> Konvertierungen immer implizit.

Hätte ich jetzt als Synonym gesehen.
Worin liegt der Unterschied?

[Frank M. (ukw) (Moderator)]

conf schrieb:
> ich denke ich werd aufgrund der Lesbarkeit den Union verwenden.

Das ist die schlechteste Begründung überhaupt. Die union ist nicht 
portabel und muss zum Endianess der CPU passen. Schön, aber falsch.

Verwende den Shift und gut ist. Das ist lesbar. Bedenke dabei auch, ob 
ein int16_t überhaupt der richtige Datentyp ist. Vermutlich ergibt sich 
aus den beiden uint8_t-Variablen nur sinnvoll eine uint16_t-Variable, 
also eine vorzeichenlose.

[Dr. Sommer (Gast)]

conf schrieb:
> ich denke ich werd aufgrund der Lesbarkeit den Union verwenden.
Lieber lesbar als funktionsfähig/korrekt?

z.B. hier wurde das alles schon lang und breit diskutiert:
Beitrag "union mit Struktur und Array gleicher Größe?"
Beitrag "Endianess beim Kopieren automatisieren"

conf schrieb:
> Hätte ich jetzt als Synonym gesehen.
Okay die Begriffe werden nicht wirklich konsistent genutzt:
http://en.cppreference.com/w/cpp/language/implicit_conversion
http://en.cppreference.com/w/cpp/language/explicit_cast

[Peter II (Gast)]

Dr. Sommer schrieb:
> Sind "falsch" und plattform-abhängig, funktioniert nur auf Little-Endian
> Prozessoren.

aber:

data = low | (high << 8);

3 Otherwise, the new type is signed and the value cannot be represented 
in it; either the result is implementation-defined or an 
implementation-defined signal is raised.

[Dr. Sommer (Gast)]

Peter II schrieb:
> 3 Otherwise, the new type is signed and the value cannot be represented
> in it;
Korrekt. Das Ergebnis hängt von der Signed-Darstellung ab. Aber fast 
alle Prozessoren nutzen 2er-Komplement, und bei denen ist das Ergebnis 
daher gleich. Das könnte man durch etwas Bitfrickelei reparieren, ist 
aber immer noch viel besser als memcpy/union/pointer umcasten, denn 
LE/BE Probleme treten viel häufiger auf, und das Signed-Problem hat man 
da genauso.

[Peter II (Gast)]

Dr. Sommer schrieb:
>> 3 Otherwise, the new type is signed and the value cannot be represented
>> in it;
> Korrekt. Das Ergebnis hängt von der Signed-Darstellung ab. Aber fast
> alle Prozessoren nutzen 2er-Komplement, und bei denen ist das Ergebnis
> daher gleich.

darum geht es doch nicht. Ein wert von 50000 lässt sich nicht in int16_t 
darstellen, damit ist das Ergebnis undefiniert. (auch wenn vermutlich 
immer das richtige rauskommt)

[Curby23523 N. (Gast)]

Dr. Sommer schrieb:
> Solche Bezeichner sind verboten und für die Standard-Library reserviert
> (alles was __ am Anfang/Ende enthält oder mit _ + Großbuchstabe
> beginnt).

Dann benenne sie um und fertig ist, dein Compiler wird schon meckern, 
wenn ihm das nicht gefällt, meine Güte erbsenzählerei hier 
Kopfschüttel ...

[Dr. Sommer (Gast)]

Peter II schrieb:
> Ein wert von 50000 lässt sich nicht in int16_t
> darstellen, damit ist das Ergebnis undefiniert. (auch wenn vermutlich
> immer das richtige rauskommt)
Ja das sag ich doch... Reden wir aneinander vorbei?

Nils H. schrieb:
> Dann benenne sie um und fertig ist
Wäre halt schlau Anfängern korrekte Code-Beispiele zu geben-

Nils H. schrieb:
> dein Compiler wird schon meckern
Die meisten Compiler meckern leider nicht. Oft funktioniert es, aber 
vielleicht funktioniert es später (neue Compiler/Standard Library 
Version) aufgrund einer Überschneidung nicht mehr; vielleicht sogar so 
dass der Compiler nicht meckert es aber trotzdem irgendwelche Probleme 
gibt.

Nils H. schrieb:
> meine Güte erbsenzählerei hier Kopfschüttel ...
Als Programmierer, insb. bei C und C++, muss man Erbsen sehr genau 
zählen damit man nicht in eine der unzähligen Fallen gerät...

[Mikro 7. (mikro77)]

Die "richtige" Lösung steht ja schon oben. Der Vollständigkeit halber...

conf schrieb:
> ich bekomme zwei Bytes die einen int16_t repräsentieren als unsigend
> char (high und low.)

Wie wurde denn der ursprüngliche int16_t zu den zwei unsigned char 
gemacht!?

[conf (Gast)]

Wenn ich das jetzt nochmal zusammenfasse, dann gibt es die richtige 
Lösung nicht da entweder

a) die Typekonvertierung nicht definiert ist und ich ggf. ein Problem 
mit anderen Compiler (oder Versionen) bekomme.

b) die Union und Pointer von der Endianess der Architektur abhängen, 
worunter die Portierbarkeit leidet.


Mikro 7. schrieb:
>
> Wie wurde denn der ursprüngliche int16_t zu den zwei unsigned char
> gemacht!?

Der kommt über eine CAN-Message die ich als ein unsigend char[] bekomme.