Strukt hat unterschiedliche länge

[Tim (Gast)]

Hallo zusammen

Ich möchte den Dateiheader eines Bitmaps in ein Strukt laden.

Dazu habe ich folgendes strukt definiert:

struct bmp_file_header
{
  unsigned char  bfType[2];
  unsigned long  bfSize;
  unsigned long   bfReserverd;
  unsigned char   bfOffset[4];
};

system ist STM32 und ARM-GCC mit CooCox IDE

Wenn ich das ganze wie im obigen Beispiel definiere, sieht mein bfOffset 
so aus:

bfOffset  0x200001e4
  bfOffset[0]  0
  bfOffset[1]  0
  bfOffset[2]  '8'
  bfOffset[3]  0


Dies ist aber Falsch!
Die '8' müsste bei bfOffset[0] liegen

Wenn ich das Strukt wie folgt definiere:

struct bmp_file_header
{
  unsigned char  bfType[2];
  unsigned char  bfSize[4];
  unsigned char   bfReserverd[4];
  unsigned char   bfOffset[4];
};

Dann sieht das ganze so aus:

bfOffset  0x200001e2
  bfOffset[0]  'F'
  bfOffset[1]  0
  bfOffset[2]  0
  bfOffset[3]  0


Und genau so sehen auch die Rohdaten des BMPs aus!
Das wäre also korrekt!

Daten werden wie folgt geladen:

bmp_f_hdr = (struct bmp_file_header *)&ucBuffer[0];

Ich dachte unsigned long ist genau 4bytes lang...

Was läuft hier schief?

[Irgendwer (Gast)]

Tim schrieb:
> Ich dachte unsigned long ist genau 4bytes lang...
>

Je nach Compilereinstellung erfolgt hierfür eine eine 
Speicherausrichtung (z.B. double-word). Wenn du also vorher zwei byte 
char hast folgen zwei Byte nichts befor dann genau auf der DWord-Granze 
der long folgt.
Bei deinem zweiten Versuch hast du nur char, da wird nichts 
ausgerichtet.

[B. S. (bestucki)]

Tim schrieb:
> bmp_f_hdr = (struct bmp_file_header *)&ucBuffer[0];

Ganz ganz unschön, fehleranfällig und nicht portabel.
Stichwort: Padding Bytes

Schreib eine Funktion, der du einen Header übergeben kannst und dir eine 
korrekt befüllte Struktur zurückliefert.

[Frank K. (fchk)]

Irgendwer schrieb:
> Tim schrieb:
>> Ich dachte unsigned long ist genau 4bytes lang...
>>
>
> Je nach Compilereinstellung erfolgt hierfür eine eine
> Speicherausrichtung (z.B. double-word). Wenn du also vorher zwei byte
> char hast folgen zwei Byte nichts befor dann genau auf der DWord-Granze
> der long folgt.
> Bei deinem zweiten Versuch hast du nur char, da wird nichts
> ausgerichtet.

genau. Und viele Prozessoren können keine nicht ausgerichteten Zugriffe, 
d.h 16 Bit an ungeraden Adressen und 32 Bit an nicht durch 4 teilbaren 
Adressen. Daher baut der Compiler Füllbytes ein, damit der Code (a) 
funktioniert oder (b) schneller abläuft. Falls er diese Füllbytes nicht 
einfügen soll, musst Du ihm das extra sagen (#pragma oder __attribute() 
oder wie auch immer, compilerspezifisch)

fchk

[c-hater (Gast)]

Tim schrieb:

> Dazu habe ich folgendes strukt definiert:

Da stellt sich bereits die erste Frage, warum hast du sie überhaupt 
selber deklariert? Du machst doch sonst auch bloß Copy&Paste, warum also 
nicht auch die Strukturdeklarationen?

>   unsigned char   bfOffset[4];

Das ist einfach Blödsinn. bfOffBits (so heißt das Feld eigentlich) ist 
ein 32Bit unsigned integer, nix anderes. War es noch nie und wird es 
auch nie sein.

> Wenn ich das ganze wie im obigen Beispiel definiere, sieht mein bfOffset
> so aus:
>
> bfOffset  0x200001e4
>   bfOffset[0]  0
>   bfOffset[1]  0
>   bfOffset[2]  '8'
>   bfOffset[3]  0

Das wäre ein sehr ungewöhnlicher Inhalt für das Feld...

Wahrscheinlich ein "Packing"-Problem. Oder anders ausgedrückt: falsche 
Strukturdeklaration. Ja, es hat seine Vorteile, wenn man die beschissene 
Sprache tatsächlich beherrscht, zu deren Verwendung man sich freiwillig 
entschieden hat...

> Die '8' müsste bei bfOffset[0] liegen

Das wäre dann aber immer immer noch ein ziemlich ungewöhnlicher Wert an 
dieser Stelle...

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Ich werfe hier für die weitere Recherche einfach mal das Wort 
"Alignment" in die Runde...