Discussion :

[muad'dib]

Salut à tous, je viens d'aller voir sur la FAQ la taille des différents types et il y a quelque chose qui me chiffonne : comment se fait-il que la taille d'un short soit la même que la taille d'un int ?

Autre chose : que signifie

De plus la relation : sizeof(short) <= sizeof(int) <= sizeof(long) est vérifiée.

Ça veut dire que la taille maximale d'un short peut atteindre la taille minimale d'un int ?? Qu'est ce que cela signifie, je croyais que de l'espace était alloué en mémoire pour chaque type : 2 octets pour un short, 4 octets pour un int. Alors comment un short peut-il prendre 2 fois plus de place qu'on n'est censé lui allouer ?

Je voudrais savoir cela car je suis entrain de programmer en ce moment une appli client/serveur et je voudrais faire de l'écriture binaire dans mon socket (fread et fwrite donc) mais je dois respecter un protocole défini : la taille de certains champs fait 8 bits, 16 bits etc... J'aurais donc besoin de connaitre quelles sont les tailles exactes de chaque type.

[crocodilex]

La taille d'un "int" dépend de l'implémentation.
Sur un processeur 16 bits, le "int" fait 2 octets, alors que sur un processeur 32 bits, il fait 4 octets.
Donc la taille d'un short est égale à un int sur un processeur 16 bits.
J'espère ne pas avoir dis trop de bétises....

[muad'dib]

La taille d'un "int" dépend de l'implémentation.
Sur un processeur 16 bits, le "int" fait 2 octets, alors que sur un processeur 32 bits, il fait 4 octets.
Donc la taille d'un short est égale à un int sur un processeur 16 bits.
J'espère ne pas avoir dis trop de bétises....

Non ça c'est vrai, mais ce qui me choque surtout c'est que la taille d'un short puisse atteindre la taille d'un int.

[droggo]

Gio,

Non ça c'est vrai, mais ce qui me choque surtout c'est que la taille d'un short puisse atteindre la taille d'un int.

Pourquoi être choqué ?

C'est la norme qui dit ça, et par conséquent l'autorise.

Et cela rappelle qu'il ne faut jamais compter sur une réflexion du genre "int, c'est 4 octets", et programmer en fonction de ces 4 octets.
Il faut toujours vérifier la taille des types utilisés.

A titre personnel par exemple, je n'utilise jamais short ou int..., mais des types définis en fonction du compilateur.

[koopajah]

Non ça c'est vrai, mais ce qui me choque surtout c'est que la taille d'un short puisse atteindre la taille d'un int.

C'est l'inverse en fait, c'est un int qui parfois peut avoir la même taille qu'un short (ca revient au même à l'arrivée mais ca montre que ca n'est pas le short qui change de taille, plutot le int qui devient plus limité)

[Emmanuel Delahaye]

Salut à tous, je viens d'aller voir sur la FAQ la taille des différents types et il y a quelque chose qui me chiffonne : comment se fait-il que la taille d'un short soit la même que la taille d'un int ?

Et pourquoi pas ? Le langage C donne des plages de valeurs minimales pour chaque type. Il se trouve que pour short et int, ce sont les mêmes. C'est écrit dans la définition, c'est comme ça, on y peut rien.

Autre chose : que signifie Ça veut dire que la taille maximale d'un short peut atteindre la taille minimale d'un int ?? Qu'est ce que cela signifie, je croyais que de l'espace était alloué en mémoire pour chaque type : 2 octets pour un short, 4 octets pour un int. Alors comment un short peut-il prendre 2 fois plus de place qu'on n'est censé lui allouer ?

Ca signifie qu'un char, un short, un int et un long peuvent avoir la même taille. Ca dépend de l'implémentation.

Sur un DSP Texas TMS320xxx, on a :

char, short, int : 16-bit
long : 32-bit

Sur un DSP Freescale (ex-Motorola) 56156, on a(vait)

char, short, int, long : 32-bit

Je voudrais savoir cela car je suis entrain de programmer en ce moment une appli client/serveur et je voudrais faire de l'écriture binaire dans mon socket (fread et fwrite donc) mais je dois respecter un protocole défini : la taille de certains champs fait 8 bits, 16 bits etc... J'aurais donc besoin de connaitre quelles sont les tailles exactes de chaque type.

Pas de chance, ça n'existe pas de façon portable en C. Il faut utiliser un tableau de unsigned char et mettre les informations octet par octet, voire bit par bit.

[teuf13]

Avec un compilateur C décent, y a généralement des types uint32_t (par exemple) dans stdint.h dont la taille est garantie

[muad'dib]

A titre personnel par exemple, je n'utilise jamais short ou int..., mais des types définis en fonction du compilateur.

Je vois. Et tu sais oú on peut les trouver ces définitions de type avec gcc ?

Pas de chance, ça n'existe pas de façon portable en C. Il faut utiliser un tableau de unsigned char et mettre les informations octet par octet, voire bit par bit

Bon ben tant pis je vais continuer à faire comme je faisais avant alors, snif dommage... moi qui pensait gagner du temps en écrivant directement les structures, c'est long de devoir formater la trame à chaque fois !

[droggo]

Jia,

Je vois. Et tu sais oú on peut les trouver ces définitions de type avec gcc ?

Tu peux te le faire facilement : pour chaque type, tu vérifies la taille avec sizeof, et tu fais les définitions en fonction de ces valeurs.

par exemple, si sizeof(int) = 4, alors définir un type int_32 pour int, etc..., et toujours utiliser ces types que tu as définis.
Le jour où tu changes de compilateur, tu n'as qu'à faire une vérification des tailles des types, et ajuster tes propres définitions si nécessaire.

[Emmanuel Delahaye]

Tu peux te le faire facilement : pour chaque type, tu vérifies la taille avec sizeof, et tu fais les définitions en fonction de ces valeurs.

par exemple, si sizeof(int) = 4, alors définir un type int_32 pour int, etc..., et toujours utiliser ces types que tu as définis.
Le jour où tu changes de compilateur, tu n'as qu'à faire une vérification des tailles des types, et ajuster tes propres définitions si nécessaire.

et l'alignement, l'endianness...

Bref autant écrire du code portable une bonne fois pour toutes, même si c'est un peu plus long. Des macros peuvent aider...

[dj.motte]

Salut,

Une chose qui m'échappe en C 32 bits c'est la différence entre "long" et 'int".

Apparemment c'est pareil sauf erreur.

Avec Java la distinction est claire. Pour avoir 64 bits avec les dernières moutures du C, il faut déclarer au moins "long long".

Je ne comprends pas, à quoi sert "long" si on ne peut pas le distinguer de "int" ?

[Médinoc]

Ça dépend de l'environnement.
Sous la plupart des environnements 32 bits, long et int ont la même taille. Sous d'autre environnements, long peut être d'une taille supérieure à int.

Exemples en C:

• DOS 16 bits: char/short/int/long/long long = 8/16/16/32/X
• TI-89: 8/16/16/32/? ('sais plus si long long existe dessus)
• Win32 ou Win64: 8/16/32/32/64
• Sans compter les plate-formes avec des systèmes unixoïdes, où il me semble que c'est souvent du genre 8/16/32/64/?

Exemples en d'autres langages:

• C# et Java: 16/16/32/64/X

[muad'dib]

Ça dépend de l'environnement.
Sous la plupart des environnements 32 bits, long et int ont la même taille. Sous d'autre environnements, long peut être d'une taille supérieure à int.

Donc pour résumer, on ne peut pas se fier à la taille mémoire des types primitifs pour faire de l'écriture binaire destinée à 2 architectures différentes.

Mais c'est quoi l'intérêt alors dans ce cas de faire un type long et un type int s'ils ont la même taille mémoire? Qu'est ce qui pousse les créateurs de compilos ou des dites architectures á définir que ces types auront des tailles identiques ?

En fait, je ne vois pas pourquoi ce ne serait pas partout comme en Java par exemple :

• char : 8 bits
• short : 16 bits
• int : 32 bits
• long : 64 bits

Ce serait plus simple

[Jean-Marc.Bourguet]

Il faut un peu d'histoire.

Si j'ai bonne memoire, l'article de John Mashey dans
http://www.acm.org/acmqueue/digital/...ctober2006.pdf
pages 27 à 37 est pertinent.

[Emmanuel Delahaye]

Donc pour résumer, on ne peut pas se fier à la taille mémoire des types primitifs pour faire de l'écriture binaire destinée à 2 architectures différentes.

Non, pour la simple raison que certaines architectures ne supportent pas ces tailles, tout simplement. Les DSP (Digital Signal Processor), par exemple ne savent souvent pas adresser des mots de 8-bit, voire des mots de 16-bit. D'autres ont des bus de 16-bit adressables en 8-bit, 16, 32 mais pas plus. Comme il y a 4 types (C90) pour 3 tailles, il y a forcément des recouvrements.

Ca n'a pas vraiment d'importance en interne si on se fie aux plages minimales garanties :

http://emmanuel-delahaye.developpez.com/init_c.htm#type

Par contre, ça empêche de faire des interfaces externes, mais ce n'est pas la seule raison. La solution est connue : tableaux de unsigned char et opérateurs bits si nécessaire.

Mais c'est quoi l'intérêt alors dans ce cas de faire un type long et un type int s'ils ont la même taille mémoire? Qu'est ce qui pousse les créateurs de compilos ou des dites architectures á définir que ces types auront des tailles identiques ?

Des contraintes matérielles.

En fait, je ne vois pas pourquoi ce ne serait pas partout comme en Java par exemple :

• char : 8 bits
• short : 16 bits
• int : 32 bits
• long : 64 bits

Ce serait plus simple

Parce que le matériel n'a pas forcément ces capacités. Java, c'est bien mais sur DSP, je demande à voir... Il ne faut pas oublier que le C peut tourner sur à peu près tout ce qui existe ou existera demain (voire après demain)...

[Tymk]

Pourquoi unsigned char est plus fiable que les autres types ? Comme les autres il a une taille minimum mais est-ce qu'il a en plus une taille fixe pour toutes les architectures ?

Si tel est le cas alors pas de problème :

Code :

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

unsigned char[2];

est un mot de 16 bits sous tous les compilateurs et on peut facilement récupérer chaque octet.

[Emmanuel Delahaye]

Pourquoi unsigned char est plus fiable que les autres types ?

Qui a dit ça ? Fiable dans quel sens ?

[Tymk]

Sauf erreur de ma part, vous avez expliquez qu'on doit passer par des unsigned char[] et non par d'autres types, pour être sûr qu'on ait le nombre d'octet attendu sur toutes les plateformes. Pour quelle raison ? Cela sgnifie-t-il que unsigned char est codé sur exactement 8 bits sur toutes les plateformes ?

[Emmanuel Delahaye]

Sauf erreur de ma part, vous avez expliquez qu'on doit passer par des unsigned char[] et non par d'autres types, pour être sûr qu'on ait le nombre d'octet attendu sur toutes les plateformes. Pour quelle raison ? Cela sgnifie-t-il que unsigned char est codé sur exactement 8 bits sur toutes les plateformes ?

Pas du tout. L'intérêt des tableaux de unsigned char est qu'il permettent de formater les données exactement comme on veut dans un flux. Rien à voir avec un type interne. Au contraire, il s'agit de format d'échange (donc externe et indépendant de la machine).

Dans un flux (fichier, réseau etc.), les données unitaires font exactement 8-bit, ce sont des octets. Un unsigned char est toujours suffisamment grand pour traiter un octet. Un tableau de unsigned char est ce qu'il faut pour stocker les données d'un flux (quelque soit la largeur d'un char, qui ne peut être < 8-bit).

[Tymk]

Merci, pour cette précision