Bonjour,
J'ai lu ici même que : sizeof (short) <= sizeof (int) et de même que
sizeof (int) < sizeof (long).
J'ai beau lire et relire la Norme, je ne vois pas où cela est garanti.
Quelqu'un peut-il préciser ? Merci
Bonjour,
J'ai lu ici même que : sizeof (short) <= sizeof (int) et de même que
sizeof (int) < sizeof (long).
J'ai beau lire et relire la Norme, je ne vois pas où cela est garanti.
Quelqu'un peut-il préciser ? Merci
Bonjour,
J'ai lu ici même que : sizeof (short) <= sizeof (int) et de même que
sizeof (int) < sizeof (long).
J'ai beau lire et relire la Norme, je ne vois pas où cela est garanti.
Quelqu'un peut-il préciser ? Merci
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 >= 0x7FFFFFFJ'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.
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.
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 >= 0x7FFFFFFJ'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.
Le Tue, 21 Jul 2009 07:11:07 +0200
Pierre Maurette a écritcandide, 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 >= 0x7FFFFFFJ'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.
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).
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.
Seules les limites min, max et umax sont imposées (dans <limits.h>),
après la taille que le compilo gère en interne c'est sa tambouille.
Tout ce qu'on lui demande c'est de savoir caster correctement et gérer
les opérations arithmétiques en concordance avec les limites imposées.
En particulier rien n'interdit qu'un short soit codé sur 128 bits et
un long sur 32 bits. Je vous l'accorde, niveau optim c'est pas
terrible, mais ça respecte la norme.
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.
Je me fourvoie peut-être, mais c'est ce que je comprends de la norme.
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.
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).
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.
Seules les limites min, max et umax sont imposées (dans <limits.h>),
après la taille que le compilo gère en interne c'est sa tambouille.
Tout ce qu'on lui demande c'est de savoir caster correctement et gérer
les opérations arithmétiques en concordance avec les limites imposées.
En particulier rien n'interdit qu'un short soit codé sur 128 bits et
un long sur 32 bits. Je vous l'accorde, niveau optim c'est pas
terrible, mais ça respecte la norme.
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.
Je me fourvoie peut-être, mais c'est ce que je comprends de la norme.
Le Tue, 21 Jul 2009 07:11:07 +0200
Pierre Maurette a écritcandide, 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 >= 0x7FFFFFFJ'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.
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).
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.
Seules les limites min, max et umax sont imposées (dans <limits.h>),
après la taille que le compilo gère en interne c'est sa tambouille.
Tout ce qu'on lui demande c'est de savoir caster correctement et gérer
les opérations arithmétiques en concordance avec les limites imposées.
En particulier rien n'interdit qu'un short soit codé sur 128 bits et
un long sur 32 bits. Je vous l'accorde, niveau optim c'est pas
terrible, mais ça respecte la norme.
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.
Je me fourvoie peut-être, mais c'est ce que je comprends de la norme.
Bonjour,
J'ai lu ici même que : sizeof (short) <= sizeof (int) et de même que
sizeof (int) < sizeof (long).
J'ai beau lire et relire la Norme, je ne vois pas où cela est garanti.
Quelqu'un peut-il préciser ? Merci
Bonjour,
J'ai lu ici même que : sizeof (short) <= sizeof (int) et de même que
sizeof (int) < sizeof (long).
J'ai beau lire et relire la Norme, je ne vois pas où cela est garanti.
Quelqu'un peut-il préciser ? Merci
Bonjour,
J'ai lu ici même que : sizeof (short) <= sizeof (int) et de même que
sizeof (int) < sizeof (long).
J'ai beau lire et relire la Norme, je ne vois pas où cela est garanti.
Quelqu'un peut-il préciser ? Merci
On parle au départ d'un sizeof. Donc là on aurait sizeof(short) = 128 /
CHAR_BIT et sizeof(long) = 32 / CHAR_BIT. Et là je suis convaincu qu'on
va tomber en contradiction avec au moins un point dans 6.2.6 avec
lecture de 6.3.1.1 et 6.2.5.8.
On parle au départ d'un sizeof. Donc là on aurait sizeof(short) = 128 /
CHAR_BIT et sizeof(long) = 32 / CHAR_BIT. Et là je suis convaincu qu'on
va tomber en contradiction avec au moins un point dans 6.2.6 avec
lecture de 6.3.1.1 et 6.2.5.8.
On parle au départ d'un sizeof. Donc là on aurait sizeof(short) = 128 /
CHAR_BIT et sizeof(long) = 32 / CHAR_BIT. Et là je suis convaincu qu'on
va tomber en contradiction avec au moins un point dans 6.2.6 avec
lecture de 6.3.1.1 et 6.2.5.8.
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.
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.
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.
sizeof (int) < sizeof (long).
sizeof (int) < sizeof (long).
sizeof (int) < sizeof (long).
In article ,
Pierre Maurette wrote:On parle au départ d'un sizeof. Donc là on aurait sizeof(short) = 128 /
CHAR_BIT et sizeof(long) = 32 / CHAR_BIT. Et là je suis convaincu qu'on
va tomber en contradiction avec au moins un point dans 6.2.6 avec
lecture de 6.3.1.1 et 6.2.5.8.
C'est ce que je pensais aussi, mais apres relecture de la norme, elle fait
tres attention de distinguer padding et representation, typiquement,
6.2.6.2.6.
Une lecture un peu rapide ne me montre pas de contradiction evidente, meme
si je ne pense pas qu'aucune implementation ne viole
sizeof(int)<=sizeof(long).
In article <mn.a9eb7d97aa440095.79899@wanadoo.fr>,
Pierre Maurette <maurettepierre@wanadoo.fr> wrote:
On parle au départ d'un sizeof. Donc là on aurait sizeof(short) = 128 /
CHAR_BIT et sizeof(long) = 32 / CHAR_BIT. Et là je suis convaincu qu'on
va tomber en contradiction avec au moins un point dans 6.2.6 avec
lecture de 6.3.1.1 et 6.2.5.8.
C'est ce que je pensais aussi, mais apres relecture de la norme, elle fait
tres attention de distinguer padding et representation, typiquement,
6.2.6.2.6.
Une lecture un peu rapide ne me montre pas de contradiction evidente, meme
si je ne pense pas qu'aucune implementation ne viole
sizeof(int)<=sizeof(long).
In article ,
Pierre Maurette wrote:On parle au départ d'un sizeof. Donc là on aurait sizeof(short) = 128 /
CHAR_BIT et sizeof(long) = 32 / CHAR_BIT. Et là je suis convaincu qu'on
va tomber en contradiction avec au moins un point dans 6.2.6 avec
lecture de 6.3.1.1 et 6.2.5.8.
C'est ce que je pensais aussi, mais apres relecture de la norme, elle fait
tres attention de distinguer padding et representation, typiquement,
6.2.6.2.6.
Une lecture un peu rapide ne me montre pas de contradiction evidente, meme
si je ne pense pas qu'aucune implementation ne viole
sizeof(int)<=sizeof(long).
Je regarde de belles images de montagne et de vélocipédistes à la télé,
je n'ai pas trop envie de regarder cette ?!!?!? de norme, et en plus
j'ai vraiment un problème avec les shall should would /and so on/.
Je considère la norme C est un document industriel technique, elle ne
décrit pas une construction mathématiquement pure, je n'ai pas vraiment
envie de la prendre en défaut, il me semble qu'on y passe facilement
beaucoup de temps. En tournant sur une demi-dourzaine de questions
toujours les mêmes.
Pragmatiquement, je crois que l'édifice s'écroule si les types "plain
C" en C89/90, C99 et C++ ne suivent pas les mêmes règles. Dont:
1 <= sizeof(char) <= /* ... */ <= sizeof(long long) avec les
contraintes supplémentaires de limits.h
Je regarde de belles images de montagne et de vélocipédistes à la télé,
je n'ai pas trop envie de regarder cette ?!!?!? de norme, et en plus
j'ai vraiment un problème avec les shall should would /and so on/.
Je considère la norme C est un document industriel technique, elle ne
décrit pas une construction mathématiquement pure, je n'ai pas vraiment
envie de la prendre en défaut, il me semble qu'on y passe facilement
beaucoup de temps. En tournant sur une demi-dourzaine de questions
toujours les mêmes.
Pragmatiquement, je crois que l'édifice s'écroule si les types "plain
C" en C89/90, C99 et C++ ne suivent pas les mêmes règles. Dont:
1 <= sizeof(char) <= /* ... */ <= sizeof(long long) avec les
contraintes supplémentaires de limits.h
Je regarde de belles images de montagne et de vélocipédistes à la télé,
je n'ai pas trop envie de regarder cette ?!!?!? de norme, et en plus
j'ai vraiment un problème avec les shall should would /and so on/.
Je considère la norme C est un document industriel technique, elle ne
décrit pas une construction mathématiquement pure, je n'ai pas vraiment
envie de la prendre en défaut, il me semble qu'on y passe facilement
beaucoup de temps. En tournant sur une demi-dourzaine de questions
toujours les mêmes.
Pragmatiquement, je crois que l'édifice s'écroule si les types "plain
C" en C89/90, C99 et C++ ne suivent pas les mêmes règles. Dont:
1 <= sizeof(char) <= /* ... */ <= sizeof(long long) avec les
contraintes supplémentaires de limits.h
Pragmatiquement, je crois que l'édifice s'écroule si les types "plain
C" en C89/90, C99 et C++ ne suivent pas les mêmes règles. Dont:
1 <= sizeof(char) <= /* ... */ <= sizeof(long long) avec les
contraintes supplémentaires de limits.h
Pragmatiquement, je crois que l'édifice s'écroule si les types "plain
C" en C89/90, C99 et C++ ne suivent pas les mêmes règles. Dont:
1 <= sizeof(char) <= /* ... */ <= sizeof(long long) avec les
contraintes supplémentaires de limits.h
Pragmatiquement, je crois que l'édifice s'écroule si les types "plain
C" en C89/90, C99 et C++ ne suivent pas les mêmes règles. Dont:
1 <= sizeof(char) <= /* ... */ <= sizeof(long long) avec les
contraintes supplémentaires de limits.h