Michael Ott <[EMAIL PROTECTED]> 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.
