Que signifie ceci ?

Le
Zouplaz
Bonjour, j'ai ceci dans un fichier header :

struct tcphdr {
/* .. snip .. */
__u16 res1:4,
doff:4,
fin:1
/* .. snip .. */
};

Que signifie le :4 et :1 ?

Merci
Vos réponses
Trier par : date / pertinence
Régis Troadec
Le #577160
Salut,

"Zouplaz"
Bonjour, j'ai ceci dans un fichier header :

struct tcphdr {
/* .. snip .. */
__u16 res1:4,
doff:4,
fin:1
/* .. snip .. */
};

Que signifie le :4 et :1 ?


Il s'agit d'entiers spécifiant la largeur des champs de bits nommés res1 (4
bits), doff (4 bits) et fin (1 bit) associés.

Un champ de bit est vu comme un entier signé ou non codé sur le nombre de
bits spécifiés (apparement non signé ici).
Le type du champ de bit est (doit être ?) un int ou unsigned int (ou encore
un autre type entier dépendant de l'implémentation), qualifié (const,
register, ...) ou non.

struct titi {
/* a est vu comme un entier signé sur 3 bits (de -4 à 3) */
int a :3;
/* b est vu comme un entier non signé sur 3 bits (de 0 à 7) */
unsigned int b :3;
};

res1 occupe 4 bits en mémoire, doff pareil et fin 1 bit. Le nombre
spécifiant la largeur du champ de bit doit être
un entier positif qui ne doit pas excéder le nombre de bits d'un objet du
type spécifié :
exple :

struct toto {
int a :32; /*dangereux, int peut être codé sur 16 bits sur certaines
plate-formes */
};


Merci...


Zouplaz
Le #576931
Régis Troadec - :

Il s'agit d'entiers spécifiant la largeur des champs de bits nommés
res1 (4 bits), doff (4 bits) et fin (1 bit) associés.

Un champ de bit est vu comme un entier signé ou non codé sur le nombre
de bits spécifiés (apparement non signé ici).
Le type du champ de bit est (doit être ?) un int ou unsigned int (ou
encore un autre type entier dépendant de l'implémentation), qualifié
(const, register, ...) ou non.

struct titi {
/* a est vu comme un entier signé sur 3 bits (de -4 à 3) */
int a :3;
/* b est vu comme un entier non signé sur 3 bits (de 0 à 7) */
unsigned int b :3;
};

res1 occupe 4 bits en mémoire, doff pareil et fin 1 bit. Le nombre
spécifiant la largeur du champ de bit doit être
un entier positif qui ne doit pas excéder le nombre de bits d'un objet
du type spécifié :
exple :

struct toto {
int a :32; /*dangereux, int peut être codé sur 16 bits sur
certaines
plate-formes */
};



Bon, je suis pas certain de bien piger...

struct cafait8bits {
unsigned int a :2;
unsigned int b :2;
unsigned int c :1;
unsigned int d :3;
};

Ca voudrait dire que cette struct représente un char (8 bits) avec la
possibilité d'accéder aux bits par groupe directement ? Et que sans ça il
aurait fallu stocker le tout dans un unsigned char et effectuer des >> pour
décaler les bits afin de lire leur valeur ?

Et dans cette struct, les bits de poids fort sont dans le membre a ?

Heu...

Anthony FLEURY
Le #576930
Zouplaz wrote:


Bon, je suis pas certain de bien piger...

struct cafait8bits {
unsigned int a :2;


2 bits donc 4 valeurs possibles : 0, 1, 2, 3

unsigned int b :2;


Pareil

unsigned int c :1;


Ici c'est un booleen en clair, 0 ou 1.

unsigned int d :3;


Et ici ca va donc de 0 à 7.

};

Ca voudrait dire que cette struct représente un char (8 bits) avec la
possibilité d'accéder aux bits par groupe directement ? Et que sans ça il
aurait fallu stocker le tout dans un unsigned char et effectuer des >>
pour décaler les bits afin de lire leur valeur ?

Et dans cette struct, les bits de poids fort sont dans le membre a ?

Heu...


Salut,
C'est bien ca.
Par contre, tu n'es pas assuré que sizeof(struct cafait8bits); soit
d'exactement 1 byte car rien n'empêche les bits de paddings. Tu es
seulement assuré qu'il n'y en aura pas au début de la structure, et donc
que l'adresse de a et l'adresse de ta structure sont les mêmes, comme dans
toute structure en fait.
C'est donc une commodité du langage pour representer les champs de bits.

De plus, savoir où sont les bits de poids fort ca dépend de ta convention et
de ta machine (little endian, big endian...).

Anthony
--
"I should have seen it would be this way
I should have known from the start what she's up to
When you have loved and you've lost someone
You know what it feels like to lose" -- The Rasmus

Serge Paccalin
Le #576929
Le jeudi 12 février 2004 à 22:52, Zouplaz a écrit dans fr.comp.lang.c :

Bon, je suis pas certain de bien piger...

struct cafait8bits {
unsigned int a :2;
unsigned int b :2;
unsigned int c :1;
unsigned int d :3;
};

Ca voudrait dire que cette struct représente un char (8 bits) avec la
possibilité d'accéder aux bits par groupe directement ?


Oui, quoiqu'un padding peut ajouter des octets à la suite.

Et que sans ça il aurait fallu stocker le tout dans un unsigned char
et effectuer des >> pour décaler les bits afin de lire leur valeur ?


Oui.

Et dans cette struct, les bits de poids fort sont dans le membre a ?


Hé non, ça dépend de l'implantation choisie, ce qui limite l'intérêt de
cette construction.

--
___________ 2004-02-13 08:21:05
_/ _ _`_`_`_) Serge PACCALIN -- sp ad mailclub.net
_L_) Il faut donc que les hommes commencent
-'(__) par n'être pas fanatiques pour mériter
_/___(_) la tolérance. -- Voltaire, 1763

Emmanuel Delahaye
Le #576677
In 'fr.comp.lang.c', Zouplaz
struct cafait8bits {
unsigned int a :2;
unsigned int b :2;
unsigned int c :1;
unsigned int d :3;
};

Ca voudrait dire que cette struct représente un char (8 bits) avec la
possibilité d'accéder aux bits par groupe directement ?


Oui.

Et que sans ça
il aurait fallu stocker le tout dans un unsigned char et effectuer des
pour décaler les bits afin de lire leur valeur ?



Et dans cette struct, les bits de poids fort sont dans le membre a ?


J'ai vu les deux cas. L'emplacement des bits n'est pas spécifié par la norme.
Ca dépend de l'implémentation. Ce n'est pas génant pour des structures
internes. Mais certains se croient malins en faisant 'coller' une structure
de bits sur du matériel (registres ou autre) ou des flux de données. Dommage,
au moindre changement de compilateur ou de rélage, ça risque de ne plus
fonctionner!

--
-ed- [remove YOURBRA before answering me]
The C-language FAQ: http://www.eskimo.com/~scs/C-faq/top.html
C-reference: http://www.dinkumware.com/manuals/reader.aspx?lib=cpp
FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/



Zouplaz
Le #576674
Emmanuel Delahaye - :


Et dans cette struct, les bits de poids fort sont dans le membre a ?


J'ai vu les deux cas. L'emplacement des bits n'est pas spécifié par la
norme. Ca dépend de l'implémentation. Ce n'est pas génant pour des
structures internes. Mais certains se croient malins en faisant
'coller' une structure de bits sur du matériel (registres ou autre) ou
des flux de données. Dommage, au moindre changement de compilateur ou
de rélage, ça risque de ne plus fonctionner!



Ca explique que dans le header en question (c'est un header linux, je veux
dire /usr/include/linux) l'auteur en délivre deux versions à coup de #ifdef
pour prendre en compte l'endianess

Bon ceci dit, j'ai quand même appris un truc et c'est aussi plutôt pratique
'tte histoire !


Moi
Le #587790
Dans l'article écrivait :

Ca explique que dans le header en question (c'est un header linux, je veux
dire /usr/include/linux) l'auteur en délivre deux versions à coup de #ifdef
pour prendre en compte l'endianess


Pas du tout, c'est dans /usr/include/netinet/tcp.h
On trouve le même sur les BSD (enfin c'est le contraire)

D'ailleurs yaka regarder le Copyright et se souvenir qui a foutu
TCP/IP dans Unix.

Publicité
Poster une réponse
Anonyme