Bytepuffer nach Struktur casten?

[ben (Gast)]

Morgen,

ich mache mir gerade Gedanken über eine Software.
Hintergrund: über eine Schnittstelle gelangen Binärdaten in den uC. 
Diese werden in einem Puffer byteweise gesammelt (Puffer ist uint8_t[]).
Anschließend soll der Puffer einem Protokoll-Parser übergeben werden, 
der eben den Datenstrom auswertet.
Das Protokoll besitzt einen Header, außerdem sind, abhängig von diesem 
Header, die Nutzdaten zu interpretieren.

Ich habe daran gedacht mir für die verschiedenen Nutzdaten-Typen jeweils 
eine Struktur zu definieren.
Nachdem der Typ bestimmt wurde würde ich mir einen Zeiger auf die 
Nutzdaten besorgen und in einen Strukturzeiger casten.
Dann kann ich bequem auf die Felder zugreifen.

Das kann natürlich mächtig ins Auge gehen, zwecks Padding und Byteorder.
Padding kann man per Attribut abschalten, die Byteorder kann man per 
Makro oder Inline-Funktion richtig drehen, wobei das Makro im Idealfall 
einfach garnix macht.

Gibt es bei diesem Vorgehen noch andere Stolpersteine?
Gibt es ein schöneres Vorgehen?
Ich habe mal gegoogelt und folgenden Thread gefunden, wo sich auch Herr 
Buchegger geäußert hat: Beitrag "Aufbau von Structs im Speicher"
Das liest sich ja als gäbs keine weiteren Probleme. Oder verletze ich 
damit schon die strict-aliasing Regel?

[Udo S. (urschmitt)]

Wenn du etwas über ein Netzwerk sendest solltest du dir angewöhnen die 
Daten immer in einem festen Format zu senden. Im Fall von integer oder 
longs hat es sich eingebürgert eine feste "Net Byte Order" zu benutzen, 
dafür gibt es in den TCP/UTP Stacks auch Makros.
Weiter solltest du dir mal "Unions" anschauen. Die dienen genau dazu 
einen Speicherbereich in mehrere logisch unterschiedliche Gliederungen 
zu unterteilen.

[ben (Gast)]

Udo Schmitt schrieb:
> Wenn du etwas über ein Netzwerk sendest solltest du dir angewöhnen die
> Daten immer in einem festen Format zu senden. Im Fall von integer oder
> longs hat es sich eingebürgert eine feste "Net Byte Order" zu benutzen,
> dafür gibt es in den TCP/UTP Stacks auch Makros.
> Weiter solltest du dir mal "Unions" anschauen. Die dienen genau dazu
> einen Speicherbereich in mehrere logisch unterschiedliche Gliederungen
> zu unterteilen.

Leider nicht das was ich gefragt habe.

1) Da meine Binärdaten als Protokoll zu interpretieren sind besitzen 
diese bereits ein "festes Format". Der Sender regelt das bereits alles.
Wenn ich von Byteorder-Problemen rede dann gehts mir darum, den 
empfangenen Frame für die Zielarchitektur aufzubereiten. Der Empfänger 
muss unter Umständen die Bytes erst neu verdrösseln.

2) Ich kenne Unions. Diese haben aber mit den gleichen Problemen zu 
kämpfen wie meine Lösung. Laut C-Standard darf man auch nur den Member 
lesen, der zuletzt geschrieben wurde (salopp ausgedrückt).

[Peter II (Gast)]

mach doch einfach ein memcpy in die Structur rein.

[ben (Gast)]

Peter II schrieb:
> mach doch einfach ein memcpy in die Structur rein.

Damit umgehe ich die mögliche Verletzung des strict-aliasing (falls es 
zu so einer kommt, da bin ich mir nicht sicher).

Das behebt weder das Padding, noch das Byteorder Problem.

[Peter II (Gast)]

ben schrieb:
> Das behebt weder das Padding,

das kann man mit einen mit einen pragma verhindern.

>  noch das Byteorder Problem.
damit muss man halb leben, wenn man Daten als Struct versenden will.

[Karl H. (kbuchegg)]

ben schrieb:

> 1) Da meine Binärdaten als Protokoll zu interpretieren sind besitzen
> diese bereits ein "festes Format".

gut.
Der wichtigste Punkt ist, dass es ein für alle mal definiert und 
festgenagelt wird, wie sich die Byte Order auf der Protokoll Ebene 
präsentiert.

> Der Sender regelt das bereits alles.

Auch gut

> Wenn ich von Byteorder-Problemen rede dann gehts mir darum, den
> empfangenen Frame für die Zielarchitektur aufzubereiten. Der Empfänger
> muss unter Umständen die Bytes erst neu verdrösseln.

Ja, das kann dir passieren.
Hast du denn so viele unterschiedliche Empfänger-Architekturen, dass das 
zum Problem werden könnte?

> 2) Ich kenne Unions. Diese haben aber mit den gleichen Problemen zu
> kämpfen wie meine Lösung. Laut C-Standard darf man auch nur den Member
> lesen, der zuletzt geschrieben wurde (salopp ausgedrückt).

Im Prinzip ja.
Es gibt nur eine Ausnahme. Und die ist, wenn man unsigned char, signed 
char oder char Arrays mit etwas anderem überlagert. Also genau der Fall 
den du hast. Wobei der C-Standard nichts darüber aussagt, ob es Padding 
Bytes gibt oder geben könnte, bzw. wie dann die Byte-Order aussieht. Der 
C-Standard legitimiert im Grunde

union convert
{
  long          i;
  unsigned char a[sizeof(long)];
};

in der Form, dass es zwar zulässig ist, das Verhalten aber von der 
Implementierung bestimmt wird.

> Oder verletze ich damit schon die strict-aliasing Regel?

Genau darum gehts bei dieser Ausnahme einer Union von irgendwas mit 
char-Arrays: die werden immer als aliased angenommen.

Mehr zu dem Thema "struct aliasing"
http://cellperformance.beyond3d.com/articles/2006/06/understanding-strict-aliasing.html

> Gibt es ein schöneres Vorgehen?
Ob schöner oder nicht, ist Geschmackssache. Eine Übertragung in Textform 
kennt diese Probleme so nicht, erzeugt aber mehr Overhead. Will man 
binär Übertragen, dann hat man diese "Probleme" und solange sich die 
Chip-Schmieden bzw. Compilerbauer dieser Welt nicht darüber einigen, 
welches die einzige wahre Byte-Order ist, bzw. wieviele Padding Bytes 
von jeder einzelnen Architektur immer gleich und an welcher Stelle 
eingefügt werden sollen, solange wird es System-Programmierer geben, die 
an den Schnittstellen nach aussen die entsprechenden Anpassungen 
einprogrammieren müssen.
Das ist ein ganz normaler Vorgang, also nichts wovor du groß Bammel 
haben musst. Sorge dafür, dass dein eingehender Datenstrom möglichst 
rasch und frühzeitig in die Systematik deines konkreten Prozessors 
gebracht wird, so dass darüber liegende Softwareschichten sich nicht 
mehr damit herumschlagen müssen. Kapsle diesen "Anpass-Code" 
einigermassen gut ein, mach es für nachfolgende 
Programmierergenerationen leicht, das alles auf eine andere Architektur 
anzupassen. Mehr kannst du nicht tun.

[Dr. Sommer (Gast)]

ben schrieb:
> Gibt es ein schöneres Vorgehen?
Man kann Binärdaten auch explizit einlesen... Man definiert sich im 
Protokoll genau in welchem Byte welche Daten stehen und welche 
Byte-Reihenfolge die Integer haben. Dann füllt man jedes Byte einzeln im 
Code manuell, und zerlegt dabei Integer mit Bitshifts. Beim Empfänger 
macht mans umgekehrt, und holt jedes Byte einzeln raus und schreibt es 
in die entsprechenden C-Variablen. Integer setzt man aus mehreren Bytes 
zusammen mit Bitshifts und "|". Das ist zwar ziemlich aufwändig, stellt 
aber sicher dass sich der Code auf jeder Plattform genau gleich verhält 
und somit das Protokoll überall gleich verstanden wird...

[ben (Gast)]

Danke dir, Karl-Heinz.

D.h., folgender Code wäre in Ordnung?

void protocolParser(uint8_t *data, uint8_t length)
{
  uint8_t payloadType;
  
  payloadType = getPayloadType(data, length);
  
  if (payloadType == PAYLOAD_TYPE_A)
  {
    domeSomething_A( (payloadA_t *) data);
  }
  else if (payloadType == PAYLOAD_TYPE_B)
  {
    domeSomething_B( (payloadB_t *) data);
  }
  else if (payloadType == PAYLOAD_TYPE_C)
  {
    domeSomething_C( (payloadC_t *) data);
  }
  else
  {
    //error
  }
}

Wobei payloadA_t, payloadB_t und payloadC_t Strukturen mit 
attribute_packed sind.

Oder sollte man vor dem Cast + Funktionsaufruf doch noch ein memcpy() 
spendieren?

[Karl H. (kbuchegg)]

ben schrieb:

> Oder sollte man vor dem Cast + Funktionsaufruf doch noch ein memcpy()
> spendieren?

Was würde dir der memcpy bringen, ausser das ein und dieselbe Bytefolge 
von A nach B kopiert wird?

Nach

void protocolParser(uint8_t *data, uint8_t length)
{
  uint8_t payloadType;
  
  payloadType = getPayloadType(data, length);
  
  if (payloadType == PAYLOAD_TYPE_A)
  {
    payloadA_t convData;
    memcpy( convData, data, length );

    domeSomething_A( &convData );
  }
...

hat sich ja nichts grundsätzliches geändert, ausser dass dieselben Bytes 
jetzt an einer anderen Stelle im Speicher stehen.
Es kann natürlich Gründe geben, warum man das tun möchte. Spontan fallen 
mir ein
* wenn data asychron befüllt wird und als Buffer daher möglichst schnell 
für die Aufnahme der nächsten Übertragung wieder zur Verfügung stehen 
soll
* wenn die Bytes in domeSomething_A die Daten verändert werden und diese 
Veränderung nicht nach aussen an den Originalen sichtbar sein soll.

[ben (Gast)]

Karl Heinz schrieb:
> Was würde dir der memcpy bringen, ausser das ein und dieselbe Bytefolge
> von A nach B kopiert wird?

Hatte Bedenken auf den selben Speicher via zwei verschiedene Pointer 
zuzugreifen. Nur weil ich während der Parameterübergabe caste und der 
Zugriff in der Unterfunktion stattfindet ändert es ja nichts daran dass 
es der selbe Zeiger ist.

Ob es notwendig ist (oder schöner) kann ich nicht beurteilen.

[Johann L. (gjlayde)]

Ja nach Architektur läuftst du auf segmentation fault (oder wie die 
ensprechende Trap dort heißen mag) wegen Alignment-Problemen.  Mit 
memcpy in ein korrekt aligntes Zielobjekt funktioniert es dann hingegen.

[Fabian O. (xfr)]

ben schrieb:
> D.h., folgender Code wäre in Ordnung?

Streng genommen nicht.

Karl Heinz schrieb:
> Mehr zu dem Thema "struct aliasing"
> http://cellperformance.beyond3d.com/articles/2006/...

Aus dem Artikel:
The converse is not true. Casting a char* to a pointer of any type other 
than a char* and dereferencing it is usually in volation of the strict 
aliasing rule.

[Ernst L. (Gast)]

Johann L. schrieb:
> Ja nach Architektur läuftst du auf segmentation fault (oder wie die
> ensprechende Trap dort heißen mag) wegen Alignment-Problemen.  Mit
> memcpy in ein korrekt aligntes Zielobjekt funktioniert es dann hingegen.

ich habe ein ähnliches problem.

ich verstehe deine aussage so, du hast ein uint8 Array und kopierst das 
mittels memcpy in eine struktur (so wie der TE).
Wenn du das auf einem 32Bitter machst, dann landen doch die einzelnen 
bytes irgendwo, aber sicher nicht da wo sie sollen, oder irre ich mich?

Bei einer packed- Struktur kannst du in einen fault laufen. Ich sehe 
also immer noch keine Lösung des Problems??

[huhuuu (Gast)]

schau dir mal die kleinen IP stacks an ..
die machen quasi deine errste idee

die Daten liegen  in einem

uint8_t eth_rxbuf[1536];

Dann gibt es dirverse typedef structs

typedef struct __attribute__((packed)){
  uint64_t         dst_mac   : 48; //48bit Dst MAC
  uint64_t         src_mac   : 48; //48bit Src MAC
  unsigned int     type      : 16; //16bit Type
} ETH_Header;

typedef struct __attribute__((packed)){
  unsigned int     hd_len    :  4; // 4bit Version
  unsigned int     ver       :  4; // 4bit Header Len
  unsigned int     tos       :  8; // 8bit Type of Service
  unsigned int     len       : 16; //16bit Packet Len
  unsigned int     id        : 16; //16bit ID
  unsigned int     flg_offs  : 16; // 3bit Flags 
  unsigned int     ttl       :  8; // 8bit Time to Live
  unsigned int     proto     :  8; // 8bit Protocol
  unsigned int     checksum  : 16; //16bit Checksum 
  unsigned long    src_ip    : 32; //32bit IP Src
  unsigned long    dst_ip    : 32; //32bit IP Dst
} IP_Header;

in den funktionen wird der eth_rxbuf  als parameter übergeben

ETH_Header *rx_eth;
IP_Header *rx_ip;

rx_eth = (ETH_Header*) &eth_rxbuf[0];
rx_ip  = (IP_Header*) &eth_rxbuf[14];

switch(rx_eth->type){
    case ETH_TYPE_IP:
         switch(rx_ip->proto){
             case IP_PROTO_ICMP:
                rx_icmp = (ICMP_Header*) &eth_rxbuf[ICMP_OFFSET];
                if(rx_icmp->type == ICMP_ECHO_REQ){
                }
                break;
         }      
         break;
           
    case ETH_TYPE_ARP:
        break;

[Steffen R. (steffen_rose)]

ben schrieb:
> Das behebt weder das Padding, noch das Byteorder Problem.

Casten ändert nicht an den Daten. Insofern ist dies kein Ansatz für die 
Lösung deines Problems.