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 ?

**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 !

**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...

**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...)

**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).

**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 ?

taille du type int

C

Vue hybride

Discussions similaires

Partager

Partager