Il me semblait avoir lu sur ce NG que la taille
d'un char en C valait 1 (sans autre précision sur l'unité) et
que cette taille pouvait être 7, 8 ou plus bits.
J'ai téléchargé la norme ISO/IEC 9899:1999 du langage C
mais je n'ai rien trouvé sur cela.
Pour ceux qui auraient également la norme, pouvez-vous
me dire à quel paragraphe je peux trouver cette info ?
Merci d'avance.
Jean
Par définition sizeof(char) vaut 1 ($6.5.3.4 paragraphe 3),
Effectivement. Merci bien Jean
Emmanuel Delahaye
In 'fr.comp.lang.c', Benoit Dejean wrote:
tous les codes C qui manipulent des bits ont un problème de portabilité par définition.
Mmm... sur toutes les plateformes[*], 1 est le masque du bit 0, 2 le masque du bit 1 etc. La portabilité des opérateirs logique est bonne. C'est celle des champs de bits qui est désastreuse. Une fois qu'on le sait, on ne les utilise qu'en interne, et tout va bien.
[*] sur PowerPC, c'est un peu space, mais une fois qu'on sait que le bit 0 d'un objet 8-bit s'appelle D7, d'un objet 16-bit D15 et 32-bit D31, tout va bien!
-- -ed- [remove YOURBRA before answering me] The C-language FAQ: http://www.eskimo.com/~scs/C-faq/top.html <blank line> FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/
In 'fr.comp.lang.c', Benoit Dejean <bnet@ifrance.com> wrote:
tous les codes C qui manipulent des bits ont un problème de portabilité
par définition.
Mmm... sur toutes les plateformes[*], 1 est le masque du bit 0, 2 le masque
du bit 1 etc. La portabilité des opérateirs logique est bonne. C'est celle
des champs de bits qui est désastreuse. Une fois qu'on le sait, on ne les
utilise qu'en interne, et tout va bien.
[*] sur PowerPC, c'est un peu space, mais une fois qu'on sait que le bit 0
d'un objet 8-bit s'appelle D7, d'un objet 16-bit D15 et 32-bit D31, tout va
bien!
--
-ed- emdelYOURBRA@noos.fr [remove YOURBRA before answering me]
The C-language FAQ: http://www.eskimo.com/~scs/C-faq/top.html
<blank line>
FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/
tous les codes C qui manipulent des bits ont un problème de portabilité par définition.
Mmm... sur toutes les plateformes[*], 1 est le masque du bit 0, 2 le masque du bit 1 etc. La portabilité des opérateirs logique est bonne. C'est celle des champs de bits qui est désastreuse. Une fois qu'on le sait, on ne les utilise qu'en interne, et tout va bien.
[*] sur PowerPC, c'est un peu space, mais une fois qu'on sait que le bit 0 d'un objet 8-bit s'appelle D7, d'un objet 16-bit D15 et 32-bit D31, tout va bien!
-- -ed- [remove YOURBRA before answering me] The C-language FAQ: http://www.eskimo.com/~scs/C-faq/top.html <blank line> FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/
EpSyLOn
On 9 Jul 2003 16:58:33 GMT, Emmanuel Delahaye wrote:
In 'fr.comp.lang.c', "Nicolas Favre-Félix" wrote:
les char sont codés sur CHAR_BIT qui vaut au minimum 8.
Citez moi UNE SEULE plateforme qui a des chars de plus de 8 bits.
Texas TMS320C54 : 16-bit Motorola 56156 : 32-bit
Mettez vos deux bras en l'air, puis effectuez avec chacun d'eux un mouvement en diagonale vers le bas puis faites les remonter suivant cette meme diagonale.
DOUBLE CASSAGE (deubeul cassèïge) !
Brice de Nice.
On 9 Jul 2003 16:58:33 GMT, Emmanuel Delahaye <emdelYOURBRA@noos.fr>
wrote:
In 'fr.comp.lang.c', "Nicolas Favre-Félix"
<n.favrefelix@__NOSPAM__free.fr> wrote:
les char sont codés sur CHAR_BIT qui vaut au minimum 8.
Citez moi UNE SEULE plateforme qui a des chars de plus de 8 bits.
Texas TMS320C54 : 16-bit
Motorola 56156 : 32-bit
Mettez vos deux bras en l'air, puis effectuez avec chacun d'eux un
mouvement en diagonale vers le bas puis faites les remonter suivant
cette meme diagonale.
On 9 Jul 2003 16:58:33 GMT, Emmanuel Delahaye wrote:
In 'fr.comp.lang.c', "Nicolas Favre-Félix" wrote:
les char sont codés sur CHAR_BIT qui vaut au minimum 8.
Citez moi UNE SEULE plateforme qui a des chars de plus de 8 bits.
Texas TMS320C54 : 16-bit Motorola 56156 : 32-bit
Mettez vos deux bras en l'air, puis effectuez avec chacun d'eux un mouvement en diagonale vers le bas puis faites les remonter suivant cette meme diagonale.
DOUBLE CASSAGE (deubeul cassèïge) !
Brice de Nice.
Éric Lévénez
Le 9/07/03 20:07, dans , « Emmanuel Delahaye » a écrit :
[*] sur PowerPC, c'est un peu space, mais une fois qu'on sait que le bit 0 d'un objet 8-bit s'appelle D7, d'un objet 16-bit D15 et 32-bit D31, tout va bien!
Alors là non. Le bit 0 est toujours D0. Tu ne confondrais pas avec le fait que le PowerPC peut-être big-endian ou little-endian ?
-- Éric Lévénez -- <http://www.levenez.com> Unix is not only an OS, it's a way of life.
Le 9/07/03 20:07, dans <Xns93B3CCC34BFA8hsnoservernet@130.133.1.4>,
« Emmanuel Delahaye » <emdelYOURBRA@noos.fr> a écrit :
[*] sur PowerPC, c'est un peu space, mais une fois qu'on sait que le bit 0
d'un objet 8-bit s'appelle D7, d'un objet 16-bit D15 et 32-bit D31, tout va
bien!
Alors là non. Le bit 0 est toujours D0. Tu ne confondrais pas avec le fait
que le PowerPC peut-être big-endian ou little-endian ?
--
Éric Lévénez -- <http://www.levenez.com>
Unix is not only an OS, it's a way of life.
Le 9/07/03 20:07, dans , « Emmanuel Delahaye » a écrit :
[*] sur PowerPC, c'est un peu space, mais une fois qu'on sait que le bit 0 d'un objet 8-bit s'appelle D7, d'un objet 16-bit D15 et 32-bit D31, tout va bien!
Alors là non. Le bit 0 est toujours D0. Tu ne confondrais pas avec le fait que le PowerPC peut-être big-endian ou little-endian ?
-- Éric Lévénez -- <http://www.levenez.com> Unix is not only an OS, it's a way of life.
Emmanuel Delahaye
In 'fr.comp.lang.c', Éric Lévénez wrote:
Le 9/07/03 20:07, dans , « Emmanuel Delahaye » a écrit :
[*] sur PowerPC, c'est un peu space, mais une fois qu'on sait que le bit 0 d'un objet 8-bit s'appelle D7, d'un objet 16-bit D15 et 32-bit D31, tout va bien!
Alors là non. Le bit 0 est toujours D0. Tu ne confondrais pas avec le fait que le PowerPC peut-être big-endian ou little-endian ?
Non, il faut lire les docs du MPC. C'est folklorique!
On m'a expliqué que c'était parce que le développement s'était fait sous forte influence d'IBM, pour qui l'organisation des bits est tordue à souhait. Il existe un mode "68k" qui permet de trouver sa numérotation favorie.
-- -ed- [remove YOURBRA before answering me] The C-language FAQ: http://www.eskimo.com/~scs/C-faq/top.html <blank line> FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/
In 'fr.comp.lang.c', Éric Lévénez <eric@levenez.com> wrote:
Le 9/07/03 20:07, dans <Xns93B3CCC34BFA8hsnoservernet@130.133.1.4>,
« Emmanuel Delahaye » <emdelYOURBRA@noos.fr> a écrit :
[*] sur PowerPC, c'est un peu space, mais une fois qu'on sait que le
bit 0 d'un objet 8-bit s'appelle D7, d'un objet 16-bit D15 et 32-bit
D31, tout va bien!
Alors là non. Le bit 0 est toujours D0. Tu ne confondrais pas avec le
fait que le PowerPC peut-être big-endian ou little-endian ?
Non, il faut lire les docs du MPC. C'est folklorique!
On m'a expliqué que c'était parce que le développement s'était fait sous
forte influence d'IBM, pour qui l'organisation des bits est tordue à souhait.
Il existe un mode "68k" qui permet de trouver sa numérotation favorie.
--
-ed- emdelYOURBRA@noos.fr [remove YOURBRA before answering me]
The C-language FAQ: http://www.eskimo.com/~scs/C-faq/top.html
<blank line>
FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/
Le 9/07/03 20:07, dans , « Emmanuel Delahaye » a écrit :
[*] sur PowerPC, c'est un peu space, mais une fois qu'on sait que le bit 0 d'un objet 8-bit s'appelle D7, d'un objet 16-bit D15 et 32-bit D31, tout va bien!
Alors là non. Le bit 0 est toujours D0. Tu ne confondrais pas avec le fait que le PowerPC peut-être big-endian ou little-endian ?
Non, il faut lire les docs du MPC. C'est folklorique!
On m'a expliqué que c'était parce que le développement s'était fait sous forte influence d'IBM, pour qui l'organisation des bits est tordue à souhait. Il existe un mode "68k" qui permet de trouver sa numérotation favorie.
-- -ed- [remove YOURBRA before answering me] The C-language FAQ: http://www.eskimo.com/~scs/C-faq/top.html <blank line> FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/
Éric Lévénez
Le 9/07/03 20:49, dans , « Emmanuel Delahaye » a écrit :
In 'fr.comp.lang.c', Éric Lévénez wrote:
Le 9/07/03 20:07, dans , « Emmanuel Delahaye » a écrit :
[*] sur PowerPC, c'est un peu space, mais une fois qu'on sait que le bit 0 d'un objet 8-bit s'appelle D7, d'un objet 16-bit D15 et 32-bit D31, tout va bien!
Alors là non. Le bit 0 est toujours D0. Tu ne confondrais pas avec le fait que le PowerPC peut-être big-endian ou little-endian ?
Non, il faut lire les docs du MPC. C'est folklorique!
J'ai lu les docs des PPC, je n'ai pas trouvé ce que tu dis. Les MPC sont bien les versions embarqués des "vrais" PowerPC ? C'est donc peut-être une spécificité de ces versions embarquées.
On m'a expliqué que c'était parce que le développement s'était fait sous forte influence d'IBM, pour qui l'organisation des bits est tordue à souhait. Il existe un mode "68k" qui permet de trouver sa numérotation favorie.
Un mode 68k quand on est en Little-Endian ? Ça doit être space :-)
-- Éric Lévénez -- <http://www.levenez.com> Unix is not only an OS, it's a way of life.
Le 9/07/03 20:49, dans <Xns93B3D402B822Ehsnoservernet@130.133.1.4>,
« Emmanuel Delahaye » <emdelYOURBRA@noos.fr> a écrit :
In 'fr.comp.lang.c', Éric Lévénez <eric@levenez.com> wrote:
Le 9/07/03 20:07, dans <Xns93B3CCC34BFA8hsnoservernet@130.133.1.4>,
« Emmanuel Delahaye » <emdelYOURBRA@noos.fr> a écrit :
[*] sur PowerPC, c'est un peu space, mais une fois qu'on sait que le
bit 0 d'un objet 8-bit s'appelle D7, d'un objet 16-bit D15 et 32-bit
D31, tout va bien!
Alors là non. Le bit 0 est toujours D0. Tu ne confondrais pas avec le
fait que le PowerPC peut-être big-endian ou little-endian ?
Non, il faut lire les docs du MPC. C'est folklorique!
J'ai lu les docs des PPC, je n'ai pas trouvé ce que tu dis. Les MPC sont
bien les versions embarqués des "vrais" PowerPC ? C'est donc peut-être une
spécificité de ces versions embarquées.
On m'a expliqué que c'était parce que le développement s'était fait sous
forte influence d'IBM, pour qui l'organisation des bits est tordue à souhait.
Il existe un mode "68k" qui permet de trouver sa numérotation favorie.
Un mode 68k quand on est en Little-Endian ? Ça doit être space :-)
--
Éric Lévénez -- <http://www.levenez.com>
Unix is not only an OS, it's a way of life.
Le 9/07/03 20:49, dans , « Emmanuel Delahaye » a écrit :
In 'fr.comp.lang.c', Éric Lévénez wrote:
Le 9/07/03 20:07, dans , « Emmanuel Delahaye » a écrit :
[*] sur PowerPC, c'est un peu space, mais une fois qu'on sait que le bit 0 d'un objet 8-bit s'appelle D7, d'un objet 16-bit D15 et 32-bit D31, tout va bien!
Alors là non. Le bit 0 est toujours D0. Tu ne confondrais pas avec le fait que le PowerPC peut-être big-endian ou little-endian ?
Non, il faut lire les docs du MPC. C'est folklorique!
J'ai lu les docs des PPC, je n'ai pas trouvé ce que tu dis. Les MPC sont bien les versions embarqués des "vrais" PowerPC ? C'est donc peut-être une spécificité de ces versions embarquées.
On m'a expliqué que c'était parce que le développement s'était fait sous forte influence d'IBM, pour qui l'organisation des bits est tordue à souhait. Il existe un mode "68k" qui permet de trouver sa numérotation favorie.
Un mode 68k quand on est en Little-Endian ? Ça doit être space :-)
-- Éric Lévénez -- <http://www.levenez.com> Unix is not only an OS, it's a way of life.
Jean
un char est codé sur 1 octet, soit 8 bits.
Non. /Au moins/ 8 bits. Pas pareil.
Puisque le char est l'unité élémentaire, on peut donc en déduire qu'en lisant un pgm C standard, qui tournera sur on ne sait pas quelle machine, on n'est pas en mesure de quantifier la quantitée de mémoire qu'utiliseront les variables? Jean
un char est codé sur 1 octet, soit 8 bits.
Non. /Au moins/ 8 bits. Pas pareil.
Puisque le char est l'unité élémentaire, on peut
donc en déduire qu'en lisant un pgm C standard,
qui tournera sur on ne sait pas quelle machine, on n'est pas
en mesure de quantifier la quantitée de mémoire qu'utiliseront
les variables?
Jean
Puisque le char est l'unité élémentaire, on peut donc en déduire qu'en lisant un pgm C standard, qui tournera sur on ne sait pas quelle machine, on n'est pas en mesure de quantifier la quantitée de mémoire qu'utiliseront les variables? Jean
Emmanuel Delahaye
In 'fr.comp.lang.c', Éric Lévénez wrote:
[*] sur PowerPC, c'est un peu space, mais une fois qu'on sait que le bit 0 d'un objet 8-bit s'appelle D7, d'un objet 16-bit D15 et 32-bit D31, tout va bien!
Alors là non. Le bit 0 est toujours D0. Tu ne confondrais pas avec le fait que le PowerPC peut-être big-endian ou little-endian ?
Non, il faut lire les docs du MPC. C'est folklorique!
J'ai lu les docs des PPC, je n'ai pas trouvé ce que tu dis. Les MPC sont bien les versions embarqués des "vrais" PowerPC ? C'est donc peut-être
Registre SIPEND page 11-8. La numérotation est... bizarre...
-- -ed- [remove YOURBRA before answering me] The C-language FAQ: http://www.eskimo.com/~scs/C-faq/top.html <blank line> FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/
In 'fr.comp.lang.c', Éric Lévénez <eric@levenez.com> wrote:
[*] sur PowerPC, c'est un peu space, mais une fois qu'on sait que le
bit 0 d'un objet 8-bit s'appelle D7, d'un objet 16-bit D15 et 32-bit
D31, tout va bien!
Alors là non. Le bit 0 est toujours D0. Tu ne confondrais pas avec le
fait que le PowerPC peut-être big-endian ou little-endian ?
Non, il faut lire les docs du MPC. C'est folklorique!
J'ai lu les docs des PPC, je n'ai pas trouvé ce que tu dis. Les MPC sont
bien les versions embarqués des "vrais" PowerPC ? C'est donc peut-être
[*] sur PowerPC, c'est un peu space, mais une fois qu'on sait que le bit 0 d'un objet 8-bit s'appelle D7, d'un objet 16-bit D15 et 32-bit D31, tout va bien!
Alors là non. Le bit 0 est toujours D0. Tu ne confondrais pas avec le fait que le PowerPC peut-être big-endian ou little-endian ?
Non, il faut lire les docs du MPC. C'est folklorique!
J'ai lu les docs des PPC, je n'ai pas trouvé ce que tu dis. Les MPC sont bien les versions embarqués des "vrais" PowerPC ? C'est donc peut-être
Registre SIPEND page 11-8. La numérotation est... bizarre...
-- -ed- [remove YOURBRA before answering me] The C-language FAQ: http://www.eskimo.com/~scs/C-faq/top.html <blank line> FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/
Nicolas Favre-Félix
Je dois admettre mon erreur, cela me semblait tellement gros que j'ai eu beaucoup de mal à y croire.
En tout cas l'un des axiome du C est : sizeof(char) = =1 retourne toujours vrai.
Alors comment le PDP-10 fait-il? ( http://pdp10.nocrew.org/gcc/ ) Il possède un <<"71-bit" double-precision integer format >> Mais alors quelle est le résultat renvoyé par sizeof avec ce type comm paramètre, car un char fait 9 bits sur cette machine? Si la fonction renvoie 8, alors un bit est en trop. Si sizeof se base sur le char pour déterminer son unité, comment cette fonction fait-elle si le nombre de bits d'un type/le nombre de bits du type char n'est pas un entier?
Je dois admettre mon erreur, cela me semblait tellement gros que j'ai eu
beaucoup de mal à y croire.
En tout cas l'un des axiome du C est : sizeof(char) = =1 retourne toujours
vrai.
Alors comment le PDP-10 fait-il?
( http://pdp10.nocrew.org/gcc/ )
Il possède un <<"71-bit" double-precision integer format >>
Mais alors quelle est le résultat renvoyé par sizeof avec ce type comm
paramètre, car un char fait 9 bits sur cette machine? Si la fonction renvoie
8, alors un bit est en trop. Si sizeof se base sur le char pour déterminer
son unité, comment cette fonction fait-elle si le nombre de bits d'un
type/le nombre de bits du type char n'est pas un entier?
Je dois admettre mon erreur, cela me semblait tellement gros que j'ai eu beaucoup de mal à y croire.
En tout cas l'un des axiome du C est : sizeof(char) = =1 retourne toujours vrai.
Alors comment le PDP-10 fait-il? ( http://pdp10.nocrew.org/gcc/ ) Il possède un <<"71-bit" double-precision integer format >> Mais alors quelle est le résultat renvoyé par sizeof avec ce type comm paramètre, car un char fait 9 bits sur cette machine? Si la fonction renvoie 8, alors un bit est en trop. Si sizeof se base sur le char pour déterminer son unité, comment cette fonction fait-elle si le nombre de bits d'un type/le nombre de bits du type char n'est pas un entier?
Jean-Marc Bourguet
"Nicolas Favre-Félix" writes:
Je dois admettre mon erreur, cela me semblait tellement gros que j'ai eu beaucoup de mal à y croire.
En tout cas l'un des axiome du C est : sizeof(char) = =1 retourne toujours vrai.
Alors comment le PDP-10 fait-il? ( http://pdp10.nocrew.org/gcc/ ) Il possède un <<"71-bit" double-precision integer format >> Mais alors quelle est le résultat renvoyé par sizeof avec ce type comm paramètre, car un char fait 9 bits sur cette machine? Si la fonction renvoie 8, alors un bit est en trop. Si sizeof se base sur le char pour déterminer son unité, comment cette fonction fait-elle si le nombre de bits d'un type/le nombre de bits du type char n'est pas un entier?
Padding. Le mot sur un PDP-10 fait 36 bits. Les doubles precisions utilisaient 2 mots (72 bits) dont un etait ignore. Si j'ai bonne memoire le format provient de la multiplication ou la multiplication de 2 entiers de 35 bits + 1 bit de signe fait 70 bits + 1 bit de signe (si j'ai bonne memoire aussi le PDP-10 etait du complement a deux, et ce format fait que le resultat de -2^35*-2^35 n'est pas representable).
A+
-- Jean-Marc FAQ de fclc: http://www.isty-info.uvsq.fr/~rumeau/fclc Site de usenet-fr: http://www.usenet-fr.news.eu.org
Je dois admettre mon erreur, cela me semblait tellement gros que j'ai eu
beaucoup de mal à y croire.
En tout cas l'un des axiome du C est : sizeof(char) = =1 retourne toujours
vrai.
Alors comment le PDP-10 fait-il?
( http://pdp10.nocrew.org/gcc/ )
Il possède un <<"71-bit" double-precision integer format >>
Mais alors quelle est le résultat renvoyé par sizeof avec ce type comm
paramètre, car un char fait 9 bits sur cette machine? Si la fonction renvoie
8, alors un bit est en trop. Si sizeof se base sur le char pour déterminer
son unité, comment cette fonction fait-elle si le nombre de bits d'un
type/le nombre de bits du type char n'est pas un entier?
Padding. Le mot sur un PDP-10 fait 36 bits. Les doubles precisions
utilisaient 2 mots (72 bits) dont un etait ignore. Si j'ai bonne
memoire le format provient de la multiplication ou la multiplication
de 2 entiers de 35 bits + 1 bit de signe fait 70 bits + 1 bit de signe
(si j'ai bonne memoire aussi le PDP-10 etait du complement a deux, et
ce format fait que le resultat de -2^35*-2^35 n'est pas representable).
A+
--
Jean-Marc
FAQ de fclc: http://www.isty-info.uvsq.fr/~rumeau/fclc
Site de usenet-fr: http://www.usenet-fr.news.eu.org
Je dois admettre mon erreur, cela me semblait tellement gros que j'ai eu beaucoup de mal à y croire.
En tout cas l'un des axiome du C est : sizeof(char) = =1 retourne toujours vrai.
Alors comment le PDP-10 fait-il? ( http://pdp10.nocrew.org/gcc/ ) Il possède un <<"71-bit" double-precision integer format >> Mais alors quelle est le résultat renvoyé par sizeof avec ce type comm paramètre, car un char fait 9 bits sur cette machine? Si la fonction renvoie 8, alors un bit est en trop. Si sizeof se base sur le char pour déterminer son unité, comment cette fonction fait-elle si le nombre de bits d'un type/le nombre de bits du type char n'est pas un entier?
Padding. Le mot sur un PDP-10 fait 36 bits. Les doubles precisions utilisaient 2 mots (72 bits) dont un etait ignore. Si j'ai bonne memoire le format provient de la multiplication ou la multiplication de 2 entiers de 35 bits + 1 bit de signe fait 70 bits + 1 bit de signe (si j'ai bonne memoire aussi le PDP-10 etait du complement a deux, et ce format fait que le resultat de -2^35*-2^35 n'est pas representable).
A+
-- Jean-Marc FAQ de fclc: http://www.isty-info.uvsq.fr/~rumeau/fclc Site de usenet-fr: http://www.usenet-fr.news.eu.org
