[C] Probleem met bitjes

[Verwijderd]

Hoi!

Ik ben TCP aan het implementeren in C en nu leek het mij mooi gestructureerd om een TCP Header als volgt te declareren:

C:

structure TCP_Header {
   u16_t src_port;
   u16_t dst_port;
   etc. etc.

   structure {
      unsigned int ack:1;
      unsigned int rst:1;
      etc.
   } flags; 
   
    etc.
};

een TCP Header (exclusief opties) = 20 bytes ... maar wat blijkt nu ... een
unsigned int <variable>:<number_of_bits>; neemt 4 bytes in het echte geheugen in. ipv de number of bits ... hierdoor wordt mijn packet opgeslagen in het geheugen te groot.

is er een manier in C om een bit te krijgen en deze ook werkelijk 1 bit in het geheugen te laten innemen? ipv 4 bytes?

would be great!
although I fear its not possible - *snif*

<span style="color:blue">.modbreak: gebruik [norml]

C++:

...

[/] tags</span>

[ Voor 27% gewijzigd door Verwijderd op 26-09-2003 22:54 . Reden: blijf eens af - door jullie edits vallen <variable> en <number_of_bits> weg :p ]

[moto-moi]

_Foutje

[ Voor 255% gewijzigd door moto-moi op 26-09-2003 19:19 . Reden: EN NOU ERVAN AF BLIJVEN .oisyn! :'( ]

[.oisyn]

Je moet je structure packen, maar dat is compiler specifiek, dus het zou wel handig zijn als je erbij zei welke compiler je gebruikte

voor MSVC++ heb je bijvoorbeeld #pragma pack (), en voor gcc heb je __attribute__ ((packed)) (geloof ik)

[Verwijderd]

ik gebruik gcc onder minix ... of is het cc? - zou niet weten of er verschil tussen zit ... ik zal even kijken naar dat __attribute__ ((packed))? hoe gaat de regel precies?

is het per regel

C:

unsigned short   ack:1    __attribute__ ((packed));  ?

[ps]
- thx voor de .modbreak tip!

[ Voor 20% gewijzigd door Verwijderd op 26-09-2003 19:58 ]

[Soultaker]

Ik geloof dat Stallman en Tanenbaum in permanente staat van oorlog verkeren, dus ik denk niet dat je onder Minix van GCC gebruik maakt.

[Verwijderd]

Soultaker schreef op 26 september 2003 @ 19:56:
Ik geloof dat Stallman en Tanenbaum in permanente staat van oorlog verkeren, dus ik denk niet dat je onder Minix van GCC gebruik maakt.

in de minix-vmd versie die ik gebruik zit gcc er wel bij

[Soultaker]

Verwijderd schreef op 26 september 2003 @ 19:59:
in de minix-vmd versie die ik gebruik zit gcc er wel bij

In dat geval kun je natuurlijk gewoon de GCC manual over Type Attributes raadplegen. (Misschien even een andere pagina opzoeken als je een andere versie van GCC gebruikt.)

[Verwijderd]

Voor het geval je niet gebruik wilt maken van compiler specifieke #pragmas e.d. kun je natuurlijk ook een char buffer gebruiken van 20 bytes. Is wel vies omdat je moet casten e.d. Maar soms verdedigbaar omdat je eigenlijk met verzamelingen van bits bezig bent niet zozeer met ints en chars zoals de C compiler ze kent. Als jouw byte volgorde anders is dan network byte order dan moet je toch vieze 'trucs' uithalen voor conversie tussen de ontvangen bitjes en jouw data representatie.

Het voorkomen van padding in structures is een pain in the ass. Bij somige compilers (gcc geloof ik) moet je het per structure member opgeven. Bij andere zoals dit:

#onthou de huidige padding modus
#zet padding maar uit
struct {
char blah;
char blah;
char bla[2];
}
#zet padding maar weer zoals het was

[ Voor 19% gewijzigd door Verwijderd op 26-09-2003 20:22 . Reden: typo + domme text ]

[AaroN]

..arelevante shit...

Voor de tcp header kun je hetzelfde principe gebruiken.
CC werkt trouwens ook perfect onder minix.

Volgens mij krijg je zo geen probs met alignment errors etc.

Jouw probleem gaat dus meer over de flags lees ik nu
je hebt 6 flags en twee nullen aan de linkerkant. Dus dan kun je gewoon een char OR-en met een flag.

C:

const u8_t ACK = 0x10; // 00010000 in bits
u8_t flags = 0;
flags = flags | ACK; // Zet de ACK flag.

Nu heb je geen bits meer nodig en platform onafhankelijk.

[ Voor 67% gewijzigd door AaroN op 26-09-2003 20:24 . Reden: toevoeging ]

[Verwijderd]

AaroN schreef op 26 September 2003 @ 20:13:
Ik volg het practicum ook:
...

ehmmm, dit heeft geen betrekking op het onderwerp? als ik het alleen met u8_t, u16_t en u32_t had afgekund dan had ik geen probleem gehad. ik wil als het ware u1_t, die ook 1bit in het geheugen inneemt ... de pseudoheader heb ik al gewoon correct gecode aangezien deze netjes allemaals bloks van 8bits heeft

[Sendy]

Linux gebruikt de volgende kernel struct in tcp.h:

C:

struct tcphdr {
        __u16   source;
        __u16   dest;
        __u32   seq;
        __u32   ack_seq;
#if defined(__LITTLE_ENDIAN_BITFIELD)
        __u16   res1:4,
                doff:4,
                fin:1,
                syn:1,
                rst:1,
                psh:1,
                ack:1,
                urg:1,
                ece:1,
                cwr:1;
#elif defined(__BIG_ENDIAN_BITFIELD)
        __u16   doff:4,
                res1:4,
                cwr:1,
                ece:1,
                urg:1,
                ack:1,
                psh:1,
                rst:1,
                syn:1,
                fin:1;
#else
#error  "Adjust your <asm/byteorder.h> defines"
#endif  
        __u16   window;
        __u16   check;
        __u16   urg_ptr;
};

Met platform afhankelijke code! Maar ik geloof dat Minix alleen op i386 draait toch?

[ Voor 8% gewijzigd door Sendy op 27-09-2003 00:11 ]

[Verwijderd]

Sendy schreef op 26 September 2003 @ 20:19:
Linux gebruikt de volgende kernel struct in tcp.h:

code:

struct tcphdr {
        __u16   source;
        __u16   dest;
        __u32   seq;
        __u32   ack_seq;
#if defined(__LITTLE_ENDIAN_BITFIELD)
        __u16   res1:4,
                doff:4,
        etc.

dat ziet er interessant uit! en zal wel eens de oplossing kunnen zijn, ik ga het even proberen

-

ik heb net ook

C:

struct {
   unsigned int   ack:1;
   unsigned int   psh:1;
   etc.
} flags      __attribute__ ((packed));

geprobeerd, maar hij bleef 4 volle bytes!

[ Voor 33% gewijzigd door Verwijderd op 26-09-2003 20:21 ]

[Sendy]

Het lijkt me dat dat wel werkt, die code compileer ik regelmatig (en ik denk heel veel anderen ook ) En het leek verdacht veel op jouw eerdere code, dus ik denk dat je de handleiding maar half gelezen hebt

[ Voor 35% gewijzigd door Sendy op 26-09-2003 20:23 ]

[Verwijderd]

Sendy schreef op 26 September 2003 @ 20:22:
Het lijkt me dat dat wel werkt, die code compileer ik regelmatig (en ik denk heel veel anderen ook ) En het leek verdacht veel op jouw eerdere code, dus ik denk dat je de handleiding maar half gelezen hebt

ik heb het geprobeerd met:

C:

u16_t    data_offset:4,
         reserved:6,
         ack=1,
         ...
         fin=1;

maar krijg dan (strict) non-portable field type compiler errors. het idee is goed ... het splitten van een 16bit unsigned int in alle losse bits ... iemand nog meer tips waar te zoeken hiervoor in manuals? - dus wat de goede code kan zijn?

[AaroN]

Als je nou gewoon mijn updated post leest en die code uitvoert werkt het honderd procent zeker, enige is dat je tijdelijk 6 maal 7 bites meer gebruikt, denk niet dat 42 bits significante geheugen problemen veroorzaken.

[Sendy]

Zijn dat errors of warnings? En welke compiler gebruikte je nu?

--edit
Aaron > Jij dacht dat jouw code platform onafhankelijk was?!? Ik zou nog eens een boekje lezen over big and little endian. Maar verder is het nette code inderdaad.

--edit 2
Grappig, ik zie nu TS eerste poging terug in het C boek. En in een oud mailing list mailtje lijkt het iets te zijn dat gcc goed kan. (Er staan natuurlijk niet bij of andere compilers het niet kunnen.)

[ Voor 98% gewijzigd door Sendy op 26-09-2003 21:06 ]

[Verwijderd]

AaroN schreef op 26 September 2003 @ 20:13:
..arelevante shit...

Voor de tcp header kun je hetzelfde principe gebruiken.
CC werkt trouwens ook perfect onder minix.

Volgens mij krijg je zo geen probs met alignment errors etc.

Jouw probleem gaat dus meer over de flags lees ik nu
je hebt 6 flags en twee nullen aan de linkerkant. Dus dan kun je gewoon een char OR-en met een flag.

C:

const u8_t ACK = 0x10; // 00010000 in bits
u8_t flags = 0;
flags = flags | ACK; // Zet de ACK flag.

Nu heb je geen bits meer nodig en platform onafhankelijk.

ja, de OR methode heb ik mensen wel zien gebruiken - maar ik vind het interessanter om mijn methode te gebruiken ... platform onafhankelijkheid heb ik nog niet over nagedacht en is misschien inderdaad wel een belangrijk punt.
/me maakt mental note.
maar toch wil ik het graag aan de praat krijgen op mijn manier ... zit lekker te puzzelen hier, maar een verlossende tip zal nooit weg zijn ;D

Sendy schreef op 26 September 2003 @ 20:49:
Zijn dat errors of warnings? En welke compiler gebruikte je nu?

Dat zijn errors ... ik gebruikte cc

[edit] wacht eens ff, hij gaat wel door met compilen - dus het zijn warnings I presume? of moet er dan expliciet (warning) voorstaan? - of duidt (strict) ook op een warning?
[edit2] warning of niet - hij geeft nog steeds aan dat de structure 4 bytes is.

[ Voor 22% gewijzigd door Verwijderd op 26-09-2003 21:07 ]

[Sendy]

Tja, cc is meestal de 'generieke' naam van een compiler (C compiler). Is het een specifieke Minux compiler? Doet-ie ANSI C?

[Verwijderd]

Sendy schreef op 26 september 2003 @ 21:08:
Tja, cc is meestal de 'generieke' naam van een compiler (C compiler). Is het een specifieke Minux compiler? Doet-ie ANSI C?

http://www.minix-vmd.org/cgi-bin/man?/usr/man++cc

Given that this "unified" compiler interface is based on the ACK ANSI-C, Pascal and Modula-2 compilers most options can be handed over to the ACK phases literally.

[ Voor 29% gewijzigd door Verwijderd op 26-09-2003 21:14 ]

[Sendy]

Wat is er trouwens fout aan 4 bytes? Dan moet je geen int gebruiken. Aan de linux kernel code te zien moet je 2 x 4 bits + 8 x 1 bit hebben. Samen 16 bit, dat ze ook gebruiken.

--edit
Kraiden > Dan lijkt 'cc' wel niet een ANSI compiler te zijn. acc, am2, gcc en kcc wel:

Cc, pc, m2, acc, apc, am2, gcc and kcc are the call names of the Minix C,
Pascal, and Modula-2 compilers. It is a unified interface to all the
different compilers that can be used under Minix. The first three call
names are used for the default compilers, the next three name the ACK
(Amsterdam Compiler Kit) compilers explicitely, gcc is the GNU project C
compiler, and lastly kcc is the name of the C-compiler used to compile
the Minix kernel.

[ Voor 68% gewijzigd door Sendy op 26-09-2003 21:20 ]

[Verwijderd]

Sendy schreef op 26 september 2003 @ 21:18:
Wat is er trouwens fout aan 4 bytes? Dan moet je geen int gebruiken. Aan de linux kernel code te zien moet je 2 x 4 bits + 8 x 1 bit hebben. Samen 16 bit, dat ze ook gebruiken.

wat er mis is met 4 bytes? - 2x4 bits + 8 x 1bit = inderdaad samen 16 bit en dat is. 16/8 = 2 bytes! of reken ik nou verkeerd?

-

ik kan niet tè lang blijven hangen op dit punt. maar wil zo graag op mijn eigen manier verder en niet zoals de mainstream unsigned 8 bit ints OR'en - ik vind mijn manier er cleaner uitzien, mais c'est une opinion.

wat trouwens vreemd is, dit is de code:

C:

struct header {
   u16_t src_port;
   u16_t dst_port;
   u32_t seq_number;
   u32_t ack_number
   struct {
      u16_t data_offset:4,
            reserved:6,
            urg:1,
            ack:1,
            rst:1,
            psh:1,
            urg:1,
            fin:1;
   } flags;
   u16_t win_sz;
   u16_t checksum;
   u16_t urg_ptr;
};

ik gebruik dan de volgende line om de size te testen:

C:

struct header header;
printf("size = %d", sizeof(header));
printf("size = %d", sizeof(header.flags));
etc.

(typo's daar gelaten) -
size's zijn:
src_port: 2
dst_port: 2
seq_number: 4
dst_number: 4
flags: 4 ()
win_sz: 2
checksum: 2
urg_ptr: 2

tel dit op en je krijgt 22 ... en wat geeft sizeof(header) ...
24

Juist! ... =/

[ Voor 61% gewijzigd door Verwijderd op 26-09-2003 21:57 ]

[sphere]

De kleinste unit die je kan nemen is een (unsigned) char. Ik gebruik zelf de |, |= etc. methodes veel in een driver voor een radiochip aan een parport om pinnen aan/uit te zetten. Als je vervolgens een hex getal in zo'n char propt, heb je zeer prettige controle over de 8 bits. Die methode van Aaron lijkt mij dan ook het prettigst om te implementeren, maar je kan natuurlijk prima je eigen type definen.

Om de 20 bytes te vullen zou je ook 5x unsigned long kunnen gebruiken, maar de C standaard definieert dit als een minimum van 32 bits, en is dus niet per se portable te zijn.

[Soultaker]

Meestal is cc een link naar de default compiler; kun je niet expliciet gcc gebruiken?

[Verwijderd]

sphere2 schreef op 26 September 2003 @ 21:54:
...

Om de 20 bytes te vullen zou je ook 5x unsigned long kunnen gebruiken, maar de C standaard definieert dit als een minimum van 32 bits, en is dus niet per se portable te zijn.

ik kreeg door deze post het idee om de code:

C:

struct header { 
   u16_t src_port; 
   u16_t dst_port; 
   u32_t seq_number; 
   u32_t ack_number 
   struct { 
      u32_t data_offset:4, 
            reserved:6, 
            urg:1, 
            ack:1, 
            rst:1, 
            psh:1, 
            urg:1, 
            fin:1, 
            win_sz:16;
   } flags; 
   u16_t checksum; 
   u16_t urg_ptr; 
};

te gebruiken. dit levert een header van 20 bytes! ... het enige wat ik hier tegen heb - is dat ik data_offset, reserved en win_sz niet in de flags structure wil - dit gaat tegen mijn "cleanness" van de code in ... so keep the ideas coming! =D

Soultaker schreef op 26 september 2003 @ 21:56:
Meestal is cc een link naar de default compiler; kun je niet expliciet gcc gebruiken?

Er staat een stukje in de handleiding van dit project. "You should compile using cc" =/

[ Voor 16% gewijzigd door Verwijderd op 26-09-2003 23:13 . Reden: iets vergeten in code ]

[Sendy]

[strikethrough]Dat sizeof() 24 teruggeeft is niet zo vreemd: 22 is per slot van rekening niet deelbaar door 4 en omdat 4 bytes een word is (en de processor daarmee rekent) lijkt mij dat wel juist.[/strikethrough] (Onzin)

Dat de flags 4 bytes zijn met een u16_t is wel vreemd natuurlijk.

--edit
Heb je dat stukje code (met de u16_t flags) overgetypt of gecopypaste (je zegt iets over tiepfouten, en ik zie er ook een (1)); weet je dan zeker dat je de juiste code gecompileerd hebt? (En jammer genoeg heb ik even geen compiler bij de hand (ik was even spelletje spelen op windows).

[ Voor 45% gewijzigd door Sendy op 27-09-2003 00:13 ]

[Verwijderd]

Sendy schreef op 26 september 2003 @ 22:59:
Dat sizeof() 24 teruggeeft is niet zo vreemd: 22 is per slot van rekening niet deelbaar door 4 en omdat 4 bytes een word is (en de processor daarmee rekent) lijkt mij dat wel juist.

Dat de flags 4 bytes zijn met een u16_t is wel vreemd natuurlijk.

--edit
Heb je dat stukje code (met de u16_t flags) overgetypt of gecopypaste (je zegt iets over tiepfouten, en ik zie er ook een (1)); weet je dan zeker dat je de juiste code gecompileerd hebt? (En jammer genoeg heb ik even geen compiler bij de hand (ik was even spelletje spelen op windows).

in de code zitten geen typo's - het is allemaal overgetyped. ik doe het project op een laptop in minix

[Verwijderd]

huh, waar is mijn post heen?

[edit] wat vaag ... hij gaf niet weer dat er nog een tweede pagina was - terwijl mijn laatste post er al stond =o

[edit 2]
naja ik ga maar alle flags OR'en dan (werkt al hier). als iemand nog een oplossing heeft, let me know! een oplossing die niemand anders heeft wordt meestal niet gewaardeerd door begeleiders, maar ik leer er zelf lekker wel het meest van

thx all for the help! (especially sendy en soultaker )
;xx

[ Voor 121% gewijzigd door Verwijderd op 26-09-2003 23:55 . Reden: [edit1] =$ [edit2] *snifz* ;D ]

[Sendy]

Dit werkt bij mij:

code:

sgr@tuner:~$ cat test.c

C:

#include <stdio.h>
#include <sys/types.h>

struct { 
        u_int16_t src_port; 
        u_int16_t dst_port; 
        u_int32_t seq_number; 
        u_int32_t ack_number;
        struct { 
                u_int16_t data_offset:4, 
                reserved:6, 
                urg:1, 
                ack:1, 
                rst:1, 
                psh:1, 
                urx:1, 
                fin:1;
        } flags;
        u_int16_t win_sz;
        u_int16_t checksum; 
        u_int16_t urg_ptr; 
} header;

struct {
        u_int16_t src_port;
        u_int16_t dst_port;
        u_int32_t seq_number;
        u_int32_t ack_number;
        u_int16_t data_offset:4,
                reserved:6,
                urg:1,
                ack:1,
                rst:1,
                psh:1,
                urx:1,
                fin:1;
        u_int16_t win_sz;
        u_int16_t checksum;
        u_int16_t urg_ptr;
} header2;

int main() {
        printf("Should be 20: %d\n", sizeof(header));
        printf("Should be 20: %d\n", sizeof(header2));
        return 0;
}

code:

sgr@tuner:~$ gcc -o test test.c
sgr@tuner:~$ ./test
Should be 20: 20
Should be 20: 20
sgr@tuner:~$

--edit
Sorry voor de grote edit

--edit 2
Heb er ook de 'linux' manier bijgestopt. *Dat is dus zonder struct*. Werkt prima. Ik denk dat je een rare compiler hebt. Oh, ik had die types die jij gebruikt niet, dus je kan het waarschijnlijk niet zo compileren..

[ Voor 48% gewijzigd door Sendy op 27-09-2003 00:09 ]

[igmar]

Verwijderd schreef op 26 September 2003 @ 20:10:
Voor het geval je niet gebruik wilt maken van compiler specifieke #pragmas e.d. kun je natuurlijk ook een char buffer gebruiken van 20 bytes. Is wel vies omdat je moet casten e.d.

Casten ? Hoezo ?

code:

struct blaat {
   unsigned int a,b;
};

union blaat2 {
    struct blaat a;
    unsigned char b[8];
};

int main(int argc, char**argv)
{
   union blaat2 a;

   printf("sizeof(union blaat2) : %d\n", sizeof(union blaat2));

   return 0;
}

Je kan struct blaat en de char array gebruiken hetzelfde geheugen, en zijn dus altijd aan elkaar gelijk. Geen typecast nodig.

[igmar]

Sendy schreef op 26 september 2003 @ 22:59:
[strikethrough]Dat sizeof() 24 teruggeeft is niet zo vreemd: 22 is per slot van rekening niet deelbaar door 4 en omdat 4 bytes een word is (en de processor daarmee rekent) lijkt mij dat wel juist.[/strikethrough]

een van de redenen dat gcc structs en datatypes op 4 bytes afrond is alignment : Veel CPU's, vooral de RISC familie vinden unaligned access niet zo erg leuk. De Intel familie zal het worst wezen bv, de ARM geeft een trap die afgevangen wordt en met wat truuks kan ie alsnog unaligned access doen.

gcc 3.x aligned zich helemaal het apezuur, ook vanwege aan aantal zaken, die ik wat vergeten ben

[riezebosch]

Soultaker schreef op 26 September 2003 @ 19:56:
Ik geloof dat Stallman en Tanenbaum in permanente staat van oorlog verkeren, dus ik denk niet dat je onder Minix van GCC gebruik maakt.

offtopic:
Als ik ff offtopic vraagje mag stellen: kan je wat meer vertellen over die oorlog? Volg momenteel namelijk module bij Tanenbaum

edit:

Tenminste, ik neem aan dat er maar één Tanenbaum is (figuurlijk dan)?

[ Voor 11% gewijzigd door riezebosch op 27-09-2003 22:10 ]

[Soultaker]

riezebosch schreef op 27 September 2003 @ 22:06:
Als ik ff offtopic vraagje mag stellen: kan je wat meer vertellen over die oorlog? Volg momenteel namelijk module bij Tanenbaum

Hmz, sorry, ik zat te denken aan de eeuwige discussies tussen Tanenbaum en Torvalds, maar daar heeft Stallman niets mee te maken. My bad. (Ik kan me zelfs voorstellen dat Stallman qua operating system design op dezelfde lijn zit als Tanenbaum, maar goed, daar weet ik feitelijk niets van.)

[riezebosch]

Bedoel je dit? Lekkere flamefesting van Torvalds! PS: Als dit te ver offtopic gaat, kap 'm dan maar af (of gooi 'm zelfs maar weg).

[Verwijderd]

/me heeft ook C++ op school maar houd het nog wel ff bij int, float of char.. vindt char al heel wat pfff

dit moesten we maken:

Toets uw pincode in: ****

De pincode was: 3824



.mobreak: Knap hoor, maar wat heeft dit nu met de topic te maken?

[ Voor 23% gewijzigd door .oisyn op 29-09-2003 16:17 ]