Langage C -- du jamais vu!

slapierre · Le 05/03/2007, à 21:38

J'aimerais avoir des explications sur la signification des 3 dernières lignes de la structure timex, c'est du jamais vu!

Je lis avec passion le livre Linux Device Drivers V3, qui fait référence à cette structure (CH7 -- Measuring Time Lapses) en plus du document RFC1589. Le fait est que dans RFC1589, la structure timex ne contient pas les fameux int :32;.

D'après ce que je comprend, la mémoire allouée de façon "anonyme" (n'est pas associée à une variable)
et est initialisée avec la valeur "32".

Tiré du code du kernel, soit le fichier <linux/timex.h> :

/*
* syscall interface - used (mainly by NTP daemon)
* to discipline kernel clock oscillator
*/
struct timex {
unsigned int modes; /* mode selector */
long offset; /* time offset (usec) */
long freq; /* frequency offset (scaled ppm) */
long maxerror; /* maximum error (usec) */
long esterror; /* estimated error (usec) */
int status; /* clock command/status */
long constant; /* pll time constant */
long precision; /* clock precision (usec) (read only) */
long tolerance; /* clock frequency tolerance (ppm)
* (read only)
*/
struct timeval time; /* (read only) */
long tick; /* (modified) usecs between clock ticks */

long ppsfreq; /* pps frequency (scaled ppm) (ro) */
long jitter; /* pps jitter (us) (ro) */
int shift; /* interval duration (s) (shift) (ro) */
long stabil; /* pps stability (scaled ppm) (ro) */
long jitcnt; /* jitter limit exceeded (ro) */
long calcnt; /* calibration intervals (ro) */
long errcnt; /* calibration errors (ro) */
long stbcnt; /* stability limit exceeded (ro) */

int :32; int :32; int :32; int :32;
int :32; int :32; int :32; int :32;
int :32; int :32; int :32; int :32;
};

Merci

Simon

BookeldOr · Le 05/03/2007, à 21:43

google: bitfields ou champ de bits
En gros, tu prends seulement 32 bits sur un entier.

slapierre · Le 05/03/2007, à 22:01

poursuivons la discussion... Quel est l'intérêt de définir de tels champs de bits s'il est possible d'accéder aux bits au moyens des "bitwise operations"? Soit :

unsigned int flag;

flag |= 0x10;
flag ^= (1 << 6);
...

Aussi, d'après ce que je viens de lire, les champs de bits non identifiés ne sont pas utilisés, donc on dirait que cet artifice est utilisé comme "padding".

Le fait est que je ne vois pas l'intérêt d'une telle manoeuvre

Simon

abetsic · Le 05/03/2007, à 22:30

Ce padding peut permettre de forcer un alignement en mémoire sur un multiple de 4 octets ou bien pour réserver de la place pour une utilisation future.

Ce sont les explications qui me viennent comme ça, je me trompe peut être.

BookeldOr · Le 05/03/2007, à 22:31

Lorsque tu utilises les champs de bits pour stocker des choses, certes c'est équivalent à des opérations logiques sur les bits, c'est une facilité. Et il me semble que certains compilateurs permettent de faire des vérifications de dépassement, à vérifier.
Utilisé comme bourrage, ça sert à beaucoup de choses : assurer une taille minimale, réserver de l'espace pour stocker d'autres choses, garder de l'espace pour plus tard ajouter des champs sans augmenter la taille de la structure pour assurer la compatibilité binaire, etc.
Dans le code du noyau c'est peut être d'autres cas particuliers, ce code n'est pas commenté?
Aussi, maintenant avec C99, on a la lib stdint.h, qui permet de définir des uint32 permettant de faire plus propre que les int : 32 dans le code.

Dernière modification par BookeldOr (Le 05/03/2007, à 22:32)

slapierre · Le 05/03/2007, à 22:53

Merci pour ces précisions, ça confirme certaines hypothèses sur l'utilisation des champs de bits dans ce type d'application.

C'est malheureusement tout les commentaires qu'il y a concernant cette structure, pour plus d'informations il faudra probablement regarder l'implémentation du daemon NTP

Au sujet de C99, je ne crois pas que ça s'applique car il y a une différence majeure entre programmer en user-space (utilisation de la librairie stantard - libc) et en kernel-space (utilisation de l'API du Kernel). Donc j'écris un driver (module) qui sera chargé dans le noyau, puis j'écris un programme qui va utiliser les fonctions fournies par le driver (au moyen de fcntl.h, unistd.h et al.)

Vraiment la lecture de ce livre (gratuit et en ligne) apporte des réponses au fonctionnement du noyau et est pour moi un nouveau défi de programmation!

Simon

BookeldOr · Le 05/03/2007, à 23:05

Pour C99, on est d'accord, c'est juste pour dire (à toi mais aussi aux autres qui passeraient sur ce thread) que si on veut faire des entiers sur 32 bits, sauf exceptions, on ne fait pas comme ça

slapierre · Le 05/03/2007, à 23:20

union de 4 chars?

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1 Le 05/03/2007, à 21:38

Langage C -- du jamais vu!

#2 Le 05/03/2007, à 21:43

Re : Langage C -- du jamais vu!

#3 Le 05/03/2007, à 22:01

Re : Langage C -- du jamais vu!

#4 Le 05/03/2007, à 22:30

Re : Langage C -- du jamais vu!

#5 Le 05/03/2007, à 22:31

Re : Langage C -- du jamais vu!

#6 Le 05/03/2007, à 22:53

Re : Langage C -- du jamais vu!

#7 Le 05/03/2007, à 23:05

Re : Langage C -- du jamais vu!

#8 Le 05/03/2007, à 23:20

Re : Langage C -- du jamais vu!

Pied de page des forums