sizeof(short)

Marc Espie a écrit :

On a tous deja rencontre des archi ou sizeof(int) = sizeof(long).

Et plus proche denous, Windows en 64-bit

Marc Espie a écrit :

On a tous deja rencontre des archi ou sizeof(int) = sizeof(long).

Et plus proche de nous, Windows en 64-bit.

In article <h44s1r$kqc$3@news.httrack.net>,
Xavier Roche <xroche@free.fr.NOSPAM.invalid> wrote:

Marc Espie a écrit :

On a tous deja rencontre des archi ou sizeof(int) = sizeof(long).

Et plus proche de nous, Windows en 64-bit.

Ah ca, tu fouilles ou tu veux, n'oublie pas de te laver les mains avant
de manger.

Le 21/07/2009 12:39, candide écrivit :

Pierre Maurette a écrit :

Dans la C99 que j'ai
sous les yeux, si on veut prouver, on doit pouvoir passer par 6.3.1.1
(définition de /integer conversion rank/), en particulier:
<CIT>
- The rank of a signed integer type shall be greater than the rank of
any signed integer type with less precision.
- The rank of long long int shall be greater than the rank of long int,
which shall be greater than the rank of int, which shall be greater than
the rank of short int, which shall be greater than the rank of signed char.
</CIT>
Ensuite on fait la relation entre le /rank/ et le /range/ en 6.2.5.8,
puis on regarde la représentation des types en 6.2.6 et la définition de
l'opérateur sizeof.

Oui, j'ai bien vu cela mais je ne vois pas en quoi cela contraint par exemple à
avoir :

sizeof(short) <= sizeof(int)

range(type) et sizeof(type) étant des choses différentes s'il y a du padding par
exemple.

OK, effectivement si tu pousses vraiment, la norme ne garantit peut-être
pas que le remplissage ne puisse être plus grand pour short que pour
int, avec au résultat
sizeof(short)>sizeof(int)

Si cela te tracasses, il faut faire un rapport d'anomalie (defect
report) auprès du comité, afin que ce point soit clarifié le plus tôt
possible (ce qui correspondra avec la prochaine révision de la norme).

J'ai du mal à trouver sur Usenet des infos _explicites_ sur cette question

Malgré tout le bien qu'il faut penser de Usenet, il ne s'agit pas de la
référence absolue en matière de normalisation C, ce rôle échouant au
groupe de travail WG14 du sous-comité de normalisation JTC1/SC22.


Antoine

Le 21/07/2009 5:36, zwim écrivit :

Le Tue, 21 Jul 2009 07:11:07 +0200
Pierre Maurette a écrit

candide, le 21/07/2009 a écrit :

Bonjour,


J'ai lu ici même que : sizeof (short) <= sizeof (int) et de même que
sizeof (int) < sizeof (long).

Je ne pense pas que le int soit obligatoirement *strictement* moins
large que le long. Simplement s'il y a égalité, ça impose que int soit
sur au moins 32 bits, INT_MAX == LONG_MAX >= 0x7FFFFFF

J'ai beau lire et relire la Norme, je ne vois pas où cela est garanti.

Quelqu'un peut-il préciser ? Merci

Il me semble que c'était explicite dans la version précédente de la
norme C, à moins que ce ne soit dans celle de C++. Dans la C99 que j'ai
sous les yeux, si on veut prouver, on doit pouvoir passer par 6.3.1.1
(définition de /integer conversion rank/), en particulier:
<CIT>
- The rank of a signed integer type shall be greater than the rank of
any signed integer type with less precision.
- The rank of long long int shall be greater than the rank of long int,
which shall be greater than the rank of int, which shall be greater
than the rank of short int, which shall be greater than the rank of
signed char.
</CIT>
Ensuite on fait la relation entre le /rank/ et le /range/ en 6.2.5.8,
puis on regarde la représentation des types en 6.2.6 et la définition
de l'opérateur sizeof.

Bah le compilateur fait ce qui lui chante à mon avis.

Mais les canons imposés sont assez stricts...

Rien à priori n'interdit que
sizeof(char)=sizeof(short)=sizeof(int)=sizeof(long)=1 et que tout ce
petit monde soit un 32 bit sur un machine 32 bits (i.e. soit
représenté par un type unique en interne).

Oui pour une implémentation sans bibliothèque standard (freestanding).
Non pour une implémentation hébergée (hosted): avec ta contrainte, il
est impossible d'implémenter <ctype.h> et <stdio.h>, en particulier il
faut pouvoir manipuler distinctement toutes les 4 milliards (2^32) de
valeurs possibles du type unsigned char, tout en ayant une
représentation distincte pour EOF.

Du moment qu'il sait caster correctement (unsigned char) 0xFFFFab en
0xab (car la norme dit UCHAR_MAX = 0xFF) et des choses de ce genre, ça
suffit.

Tut! Relis-toi au-dessus, et tu verras qu'il y a un pépin, UCHAR_MAX
vaut plutôt 0xFFFFFFFF avec tes hypothèses.

Seules les limites min, max et umax sont imposées (dans <limits.h>),

Non : il est aussi imposé aux types non signés de représenter toutes les
valeurs entre 0 (incluse) et 2 puissance N (exclue) ; ou si tu préfères,
que umax+1 soit une puissance entière de 2.

Avec C99, il est aussi imposé que max+1 ait la même contrainte, et de
même pour ou bien -min ou bien 1-min

Du coup, les concepteurs ont fait rimer limits.h avec la taille
utilisée en interne pour la représentation pour plus de simplicité et
de bon sens, mais à mon avis rien n'est imposée par la norme à ce
niveau.

Non. Les concepteurs écrivent les valeurs des macros décrites par la
clause 5 (limits.h et float.h) en fonction des caractéristiques
apparentes du code généré par le compilateur pour l'architecture donnée.

La norme donne des contraintes à respecter par le compilateur (et donc
une certaine marge de liberté), mais une fois que le compilateur est
défini (en fonction d'une architetcure cible, d'un niveau de
performances etc.) les valeurs se déduisent automatiquement.


Antoine

Antoine Leca a écrit :

Si cela te tracasses, il faut faire un rapport d'anomalie (defect
report) auprès du comité, afin que ce point soit clarifié le plus tôt
possible (ce qui correspondra avec la prochaine révision de la norme).

Tiens, c'est curieux mais ce n'est pas la première fois que tu me proposes très
sérieusement de faire un /Defect Report/. Mon expérience très réduite et ma
connaissance très limitée de la programmation, des systèmes, du langage C et de
la Norme ne m'autorisent pas à ce genre d'intervention. Et de toute façon, la
question n'est pas vraiment là :

*) d'une part, je ne suis pas certain qu'il y ait besoin de clarification ; on
N'a certes PAS en théorie

sizeof(short) <= sizeof(int)

mais ça ne semble pas vraiment gênant puisqu'en pratique c'est visiblement
TOUJOURS réalisé (d'ailleurs, le fait que j'aie trouvé assez difficilement de
l'information à ce sujet prouve bien que la question est de peu d'importance).

*) d'autre part, mon point de vue n'est pas du tout de corriger la Norme. Cette
Norme elle est comme elle est, création humaine imparfaite et je la prends comme
telle. Je regarde plutôt comment la Norme me transmet l'information, quel est
son degré de cohérence interne, d'homogénéité, de rigueur dans l'exposition.

Donc la rédaction de la Norme concernant sizeof(short) vs sizeof(int) ne me
tracasse pas, loin de là.


Par contre, OUI, ce qui me tracasse c'est d'avoir lu de façon répétée sur ce
forum et sur son homologue anglophone qu'on avait :

sizeof (char) <= sizeof (short) <= sizeof (int) <= sizeof (long)

et ceci affirmé par des personnes qui ont de toute évidence une très grande
expérience de la programmation C (et souvent d'autres langages) ainsi qu'une
grande pratique de l'exégèse de la Norme. Pourtant personne n'a contredit ni
même chercher à vérifier. Conséquence : ces information (fausses ?) sont
répétées à l'envi.

candide <candide@free.invalid> writes:

| Antoine Leca a écrit :
|
| > Si cela te tracasses, il faut faire un rapport d'anomalie (defect
| > report) auprès du comité, afin que ce point soit clarifià © le plus tôt
| > possible (ce qui correspondra avec la prochaine révision de la nor me).
| >
|
|
| Tiens, c'est curieux mais ce n'est pas la première fois que tu me pr oposes très
| sérieusement de faire un /Defect Report/. Mon expérience trà ¨s réduite et ma
| connaissance très limitée de la programmation, des système s, du langage C et de
| la Norme ne m'autorisent pas à ce genre d'intervention. Et de toute façon, la
| question n'est pas vraiment là :
|
| *) d'une part, je ne suis pas certain qu'il y ait besoin de clarification ; on
| N'a certes PAS en théorie
|
| sizeof(short) <= sizeof(int)

Les règles de promotions promotent 'short' en 'int'.

[...]

| Par contre, OUI, ce qui me tracasse c'est d'avoir lu de façon rà ©pétée sur ce
| forum et sur son homologue anglophone qu'on avait :
|
| sizeof (char) <= sizeof (short) <= sizeof (int) <= sizeof (long)

promotion int -> long. Tu as toujours sizeof (char) <= sizeof (T)
où T est n'importe quel type de donnée complet.

-- Gaby

Gabriel Dos Reis a écrit :

| *) d'une part, je ne suis pas certain qu'il y ait besoin de clarification ; on
| N'a certes PAS en théorie
|
| sizeof(short) <= sizeof(int)

Les règles de promotions promotent 'short' en 'int'.

Cette remarque est un peu elliptique pour moi. Dois-je comprendre que par un
chemin tortueux on pourrait finalement déduire de la Norme qu'on a toujours
sizeof(short) <= sizeof(int) ?

Pour que les choses soient claires, je précise que je crois voir dans la règle
que tu rappelles ci-dessus l'expression de :

6.3.1.8 p1
(...)
Otherwise, if both operands have signed integer types or both have unsigned
integer types, the operand with the type of lesser integer conversion rank is
converted to the type of the operand with greater rank.

et qu'ensuite on a rk(short)< rk(int).

Je crois savoir que l'étendue ("range") de short est incluse dans celle de int.
Maintenant je ne vois pas le rapport avec notre problème de sizeof(short)
comparé à sizeof(int).

promotion int -> long.

Mêmes interrogations que ci-dessus.

Tu as toujours sizeof (char) <= sizeof (T)
où T est n'importe quel type de donnée complet.

C'est quoi "complet" ?? Ah oui, un type incomplet n'a pas de sizeof, même pas 0.
Bon sinon, oui, sizeof(char) = 1 et je ne m'interrogeais pas sur la véracité
de sizeof (char) <= sizeof (T).

Bonjour,

Il y a un truc que je ne comprends pas dans ton raisonnement :

Le 23 juillet 2009, candide a écrit :

on N'a certes PAS en théorie

sizeof(short) <= sizeof(int)

mais ça ne semble pas vraiment gênant puisqu'en pratique c'est visiblement
TOUJOURS réalisé

Par contre, OUI, ce qui me tracasse c'est d'avoir lu de façon répétée sur ce
forum et sur son homologue anglophone qu'on avait :

sizeof (char) <= sizeof (short) <= sizeof (int) <= sizeof (long)

et ceci affirmé par des personnes qui ont de toute évidence une très grande
expérience de la programmation C

Quel est le problème ? S'ils ont une très grande expérience, et qu'ils ont
toujours vu qu'en pratique c'est vrai, pourquoi ne l'affirmeraient-ils
pas ?

--
LL

Lucas Levrel a écrit :

Quel est le problème ? S'ils ont une très grande expérience, et qu'ils ont
toujours vu qu'en pratique c'est vrai, pourquoi ne l'affirmeraient-ils
pas ?

Mais il n'affirment pas qu'"en pratique c'est vrai", mais que "c'est vrai" et
dans un contexte tel qu'on a toutes raisons de penser que le langage est ainsi
spécifié (c'est d'ailleurs formulé ainsi parfois). D'autres sont plus prudents,
par exemple Richard Heathfield ici :

http://groups.google.fr/group/alt.solaris.x86/msg/18c4481b0d082ecb?hl=fr