Re: gcc und 32bit grenze
Michael Ott <michael@zolnott.de> writes:
> Hallo Bruno!
>
>> > Ich lese gerade mittels socket eine Struct, das sich nicht an die
>> > 32bit-Grenze nicht hält.
>> >
>> > Ich habe folgendes Strukt:
>> > struct {
>> > char[10];
>> > int;
>> > }
>> > und genau das bekomme ich über das Netz, nur das er mir wirklich 10bit
>> > und danach die Zahl bringt,
>>
>> 10 Byte wahrscheinlich. Und wo ist das Problem? Du sagst es wird alles
>> übertragen, erst 10 und dann nochmal 4 Byte. Da sehe ich weit und
>> breit kein Problem, und wenn da eines wäre hat es mit einer wie immer
>> gearteten 32bit Grenze vermutlich gar nichts zu tun.
>>
>> Weisst du nicht wie du die 14 Byte korrekt lesen sollst, oder wo
>> hapert es? Mit etwas Quellcode ließe sich nebenbei vielleicht mehr
>> sagen.
> gcc schreibt aber intern das int nicht gleich hinter die chars, sondern
> fängt an der nächsten 32bit-Grenze an. Und dabei liegt das Problem. Die
> Daten aus dem Socket sind aber hintereinander weg geschrieben.
>
> Ich habe mir die Speicheraddressen ausgegeben und da fängt das int vom
> Socket zwei Bytes vor dem dem int aus der Struktur an.
>
> Ich habe dabei die Bytes mir einzeln ausgelesen
Ah, OK. Du deklarierst ein analoges struct auf der receiver Seite und
da passt es nicht mehr. Das Schlagwort hier heißt 'struct padding'.
Zwei Alternativen:
struct {
char[10];
int;
} __atribute__((packed));
oder du stellst das int einfach an den Anfang, natürlich auf sender
und receiver Seite
struct {
int;
char[10];
}
Generell, und insbesondere wenn binäre Daten über's Netzwerk gehen
sollen, empfiehlt es sich in structs die 'dicken Teile' an den Anfang
zu stellen, d.h. zumindest die Teile, die auf alignment boundaries
fallen.
Gruss, Bruno.
Reply to: