taille du type int

**Biosox** · 20/06/2007, 14h12

bonjour.
Est-ce que selon vous le test lors du préprocesseur:

#if ( UINT_MAX == 0xFFFFFFFF )

est suffisant pour m'assurer que les "unsigned int" sont codé sur 32 bits sur la machine sur laquelle je compile? (ou est-ce que si ce n'est pas le cas il risque d'y avoir un cast ou je ne sais quoi qui ferait que ce test puisse passer quand même?)
Merci

(Pour connaître la taill des char, il y a CHAR_BIT. (limits.h)
Mais il n'existe pas de INT_BIT ni de SHORT_BIT.)

**aurelman** · 20/06/2007, 14h31

Bonjour,

Un sizeof(int) retourne quoi ?

**Biosox** · 20/06/2007, 15h37

hello,
J'y avais pensé:
le sizeof(int) retourne bien 4, mais je souhaite faire le test lors du preprocesseur et je ne peux pas faire de

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

#if(sizeof(int) == 4)

le compilo me retourne:

fatal error C1017: invalid integer constant expression

**DaZumba** · 20/06/2007, 15h44

Ben oui, sizeof est deja gere par le pre-processeur, et on ne peut pas appliquer le pre-processeur sur lui-meme.
La question est, pourquoi tu as besoin de t'assurer de la taille d'un int dans ton code source? Normalement, c'est le Makefile qui s'occupe de ce genre de detail et prepare des codes (ou des compilations) differents selon la plateforme cible.

**Médinoc** · 20/06/2007, 15h59

Mais justement, l'on n'est pas forcément sûr des définitions.
Pour vérifier en compile-time, tu peux utiliser ceci:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

typedef int COMPILE_TIME_ASSERT_SIZEOF_INT[ (sizeof(int)==4) ? 1 : -1 ];

Ceci produit une erreur de compilation (tableau de taille négative) si la condition sizeof(int)==4 n'est pas vérifiée.
Par contre, je n'ai pas trouvé moyen de vérifier l'endianness d'un système en compile-time. Pour cela, il faudrait jouer avec des pointeurs, et les données pointées par un tableau converti en pointeur ne sont pas une constante connue à la compilation.

DaZumba: L'erreur n'est-elle pas justement que sizeof n'est PAS géré par le préprocesseur, mais par le compilateur lui-même ?

**Biosox** · 20/06/2007, 16h00

Hello,

En gros, j'écris un code qui va causer à un device via le port série. le protocole utilisé pour parler avec ce device est basé sur des mots de 8 bits.

ça me convient parfaitement, j'utilise des unsigned char (uint8) puisque chez moi ils font 8 bits (CHAR_BIT == 8)
Et mon code prépare des messages dans un buffer: uint8 buffer[MAX_SIZE]

Si un jour un char ne fait pas 8 bits sur une machine, ça risque de ne plus marcher. (selon la norme, un char fait "au minimum" 8 bits)

Je souhaite donc simplement addresser un message au programmeur qui reprendra mon code dans quelque années, quand le programme ne marchera plus et que personne ne saura pourquoi. Le but c'est qu'il reprenne le code, le compile et reçoive un message qui dit

#if(CHAR_BIT != 8)
#error "char type on this computer is not 8 bit long"
#endif

Comme ça il saura directement pourquoi ça marche plus et il sera a même de faire les modif necessaires.

jusque la tout va bien, j'ai CHAR_BIT pour controler

Mais il y a certains cas ou ça m'arrangerait de faire la même vérification pour des types de 16 et 32 bits.
Pour l'instant, la solution que j'ai trouvé c'est le test ci-dessus.
La question c'est: est-ce que ce test échouera si "unsigned int" ne fait pas 32 bits?
Selon moi, oui, mais je souhaite une confirmation

**Médinoc** · 20/06/2007, 16h07

Si tu utilises mes tests, je te conseille quand même d'utiliser un type "avec taille" plutôt que int.

Genre, ceci:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
typedef int INT32;
 
typedef int COMPILE_TIME_ASSERT_CHAR_BIT[ (CHAR_BIT==8) ? 1 : -1 ];
typedef int COMPILE_TIME_ASSERT_SIZEOF_INT32[ (sizeof(INT32)==4) ? 1 : -1 ];

Quand le second test foire, il suffit alors de changer le typedef et recompiler...

**DaZumba** · 20/06/2007, 16h18

Envoyé par Médinoc

DaZumba: L'erreur n'est-elle pas justement que sizeof n'est PAS géré par le préprocesseur, mais par le compilateur lui-même ?

Oui -- mon post etait mal ecrit. Voir cette explication qui est plus detaillee !

**Jean-Marc.Bourguet** · 20/06/2007, 17h02

Envoyé par Biosox

bonjour.
Est-ce que selon vous le test lors du préprocesseur:

est suffisant pour m'assurer que les "unsigned int" sont codé sur 32 bits sur la machine sur laquelle je compile? (ou est-ce que si ce n'est pas le cas il risque d'y avoir un cast ou je ne sais quoi qui ferait que ce test puisse passer quand même?)
Merci

(Pour connaître la taill des char, il y a CHAR_BIT. (limits.h)
Mais il n'existe pas de INT_BIT ni de SHORT_BIT.)

Oui et non. Ca suffit pour determiner que les valeurs des unsigned sont codees sur 32 bits mais ne va pas trouver les cas ou unsigned fait 32 bits avec des bits de padding et va trouver les cas ou unsigned fait plus de 32 bits mais les bits supplementaires sont des bits de padding. Il n'est pas invraissemblable que ca te convienne mieux que l'equivalent d'un sizeof(int)*CHAR_BIT == 32.

**Biosox** · 20/06/2007, 17h17

Merci a tous.

Médinoc: c'est futé. J'avais déja vu une tecnihque du genre, pas avec un typedef, mais avec une declaration de fonction qui prenait comme argument un tableau avec un indice négatif. le typedef est bien plus simple. N'ayant jamais utilisé typedef pour créer un "type tableau", je n'y avais pas pensé.

Jean-Marc.Bourget, merci pour ces précisions. Dans ce cas je pense que je vais en rester avec mon test finalement

**Médinoc** · 20/06/2007, 18h26

Remercie Microsoft, j'ai trouvé ça dans leurs headers

**Emmanuel Delahaye** · 20/06/2007, 18h50

Envoyé par Biosox

Est-ce que selon vous le test lors du préprocesseur:
<...>
est suffisant pour m'assurer que les "unsigned int" sont codé sur 32 bits sur la machine sur laquelle je compile?

A quoi ça sert de savoir si un unsigned int est codé sur 32-bit ?

**Emmanuel Delahaye** · 20/06/2007, 18h52

Envoyé par DaZumba

Ben oui, sizeof est deja gere par le pre-processeur,

Euh, non. le préprocésseur est évalué dans les phases 1 ou 2 de la compilation. Les expression constantes dans les phase 3 ou 4 ...

On ne peut donc pas utiliser une expression constante calculée dans le préprocesseur. (Par contre on peut faire un assert() qui se déclenchera éventuellement à l'exécution).

**Emmanuel Delahaye** · 20/06/2007, 18h59

Envoyé par Biosox

En gros, j'écris un code qui va causer à un device via le port série. le protocole utilisé pour parler avec ce device est basé sur des mots de 8 bits.

ça me convient parfaitement, j'utilise des unsigned char (uint8) puisque chez moi ils font 8 bits (CHAR_BIT == 8)
Et mon code prépare des messages dans un buffer: uint8 buffer[MAX_SIZE]

Si un jour un char ne fait pas 8 bits sur une machine, ça risque de ne plus marcher. (selon la norme, un char fait "au minimum" 8 bits)

Il n'y a aucune raison que ça ne fonctionne pas. Sur un DSP où les char font 16-bit, les chaines de caractères prennent plus de place que nécessaire (un DSP, c'est pas fait pour traiter des chaines de caractères), mais le fonctionnement reste conforme.

Tu te crées des soucis pour rien. Il faut au contraire savoir écrire du code portable qui fait qu'on a absolument pas à faire attention à ce genre de détails sans intérêt.

Pour répondre à ta question initiale, si tu as besoin de 32-bit, tu utilises un unsigned long. Point. Ca, c'est 'savoir écrire du code portable'.

Utiliser un int pour 32-bit, c'est sortir le gros bâton pour se faire taper dessus (ou se tirer une balle dans le pied...)

**Médinoc** · 20/06/2007, 22h05

En fait, je ne vois qu'une seule chose qui nécessite d'avoir des tailels connues et constantes : La sérialisation de données sous forme binaire.
Utilisée pour les fichiers binaires, et pour certains protocoles de couche 4 et supérieur.

Pour les fichiers texte ou les protocoles texte, la taille réelle d'un type importe peu par rapport à sa capacité minimale...

**Emmanuel Delahaye** · 21/06/2007, 02h22

Envoyé par Médinoc

En fait, je ne vois qu'une seule chose qui nécessite d'avoir des tailels connues et constantes : La sérialisation de données sous forme binaire.
Utilisée pour les fichiers binaires, et pour certains protocoles de couche 4 et supérieur.

Pour les fichiers texte ou les protocoles texte, la taille réelle d'un type importe peu par rapport à sa capacité minimale...

Bah non. Vu qu'on est censés traiter les flux de bytes avec des tableaux de unsigned char, je ne vois pas à quoi ça servirait. Les interfaces binaires réelles (pas les bricolages de coin de table) sont définis indépendamment des détails de l'implémentation. (XDR, BER etc.)

Et même dans les champs des protocoles, la définition est faite en N octets avec indication de la position du MSB.

Jamais il n'est fait référence à des champs de bits C ou à des types C. Ce serait absurde....

**Médinoc** · 21/06/2007, 09h10

Tiens, c'est vrai.
Donc, une fois ça en tête, il n'est même plus nécessaire de connaître la vraie taille, puisqu'on travaille partout en flux d'octets.

Évidemment, ça redevient nécessaire quand on se met à faire du bricolage (comme l'écriture directe de structures dans des flux). Mais bon, c'est du bricolage, donc faut pas s'étonner...

**Biosox** · 21/06/2007, 15h19

Envoyé par Emmanuel Delahaye

Tu te crées des soucis pour rien. Il faut au contraire savoir écrire du code portable qui fait qu'on a absolument pas à faire attention à ce genre de détails sans intérêt.

Sans doute. Je ne sais pas écrire du code portable.

Envoyé par Emmanuel Delahaye

Pour répondre à ta question initiale, si tu as besoin de 32-bit, tu utilises un unsigned long. Point. Ca, c'est 'savoir écrire du code portable'.

Merci! Je note

Envoyé par Emmanuel Delahaye

Utiliser un int pour 32-bit, c'est sortir le gros bâton pour se faire taper dessus (ou se tirer une balle dans le pied...)

pas taper

**Biosox** · 21/06/2007, 15h21

Envoyé par Emmanuel Delahaye

Les interfaces binaires réelles (pas les bricolages de coin de table) sont définis indépendamment des détails de l'implémentation. (XDR, BER etc.)

Et même dans les champs des protocoles, la définition est faite en N octets avec indication de la position du MSB.

qu'est-ce que tu appelles au juste une "interface binaire réelle" ?

**Emmanuel Delahaye** · 22/06/2007, 17h33

Envoyé par Biosox

qu'est-ce que tu appelles au juste une "interface binaire réelle" ?

Quand on utilise un fichier de données (ou un flux binaire en général) qui transporte des données sous forme binaire (par opposition à textuelle, genre ASCII), on doit définir comment sont codées les données, et ce indépendamment de toute implémentation (évidemment, sinon, comment être multi-plateforme).

C'est le cas, par exemple, des protocoles SNMP (BER) et RFP (XDR). Pour les détails, Google est ton ami.

http://emmanuel-delahaye.developpez....m#enreg_struct

taille du type int

C

Discussions similaires

Partager

Partager