Alors vous êtes sorti du cadre de la norme. Celle-ci ne s'occupe pas de
normaliser l'utilisation des sorties (ni celle des entrées, d'ailleurs).
Alors vous êtes sorti du cadre de la norme. Celle-ci ne s'occupe pas de
normaliser l'utilisation des sorties (ni celle des entrées, d'ailleurs).
Alors vous êtes sorti du cadre de la norme. Celle-ci ne s'occupe pas de
normaliser l'utilisation des sorties (ni celle des entrées, d'ailleurs).
Dans l'article <c5lg7q$5vd$,
Antoine Leca écrit:On ne doit pas avoir la même manière de lire...
« N'importe quel compilateur », c'est clairement à mon sens
l'obligation de ne pas dépendre du compilateur. Donc de ne pas
s'intéresser aux particularités de tel ou tel.
Non, justement s'il veut pouvoir compiler avec n'importe quel
compilateur, il faut s'intéresser aux particularités de tous
les compilateurs
(sous réserve que celles-ci "respectent la
norme"), tout comme il ne faut pas supposer que int, long et
long long aient telle ou telle taille (cf discussion récente
sur le fait que Microsoft utilisait des tailles particulières).
Dans la norme, c'est tellement défini à l'avance que cela l'est
avant même le début de la compilation: ce codage est « défini par
l'implémentation », ce qui signifie que le fournisseur du
compilateur est obligé de le préciser dans la documentation.
En tout cas, ce n'est pas le cas avec gcc.
éventuellement a sur des systèmes non POSIX).
D'accord qu'il y ait une différence si tu ne considères que le jeu de
base. Mais cela n'empêche que c'est *dépendant de l'implémentation*.
Tu obtiendras toujours un 'a', mais son code est dépend de
l'implémentation.
[3] Both the basic source and basic execution character sets shall
have the following members: [...]
Faut-il comprendre le "shall have" comme un "shall have only" ou un
"shall have at least". Dans la langue courante, ce serait un "shall
have at least", mais qu'en est-il de l'interprétation de la norme?
Dans l'article <c5lg7q$5vd$1@shakotay.alphanet.ch>,
Antoine Leca <root@localhost.gov> écrit:
On ne doit pas avoir la même manière de lire...
« N'importe quel compilateur », c'est clairement à mon sens
l'obligation de ne pas dépendre du compilateur. Donc de ne pas
s'intéresser aux particularités de tel ou tel.
Non, justement s'il veut pouvoir compiler avec n'importe quel
compilateur, il faut s'intéresser aux particularités de tous
les compilateurs
(sous réserve que celles-ci "respectent la
norme"), tout comme il ne faut pas supposer que int, long et
long long aient telle ou telle taille (cf discussion récente
sur le fait que Microsoft utilisait des tailles particulières).
Dans la norme, c'est tellement défini à l'avance que cela l'est
avant même le début de la compilation: ce codage est « défini par
l'implémentation », ce qui signifie que le fournisseur du
compilateur est obligé de le préciser dans la documentation.
En tout cas, ce n'est pas le cas avec gcc.
éventuellement a sur des systèmes non POSIX).
D'accord qu'il y ait une différence si tu ne considères que le jeu de
base. Mais cela n'empêche que c'est *dépendant de l'implémentation*.
Tu obtiendras toujours un 'a', mais son code est dépend de
l'implémentation.
[3] Both the basic source and basic execution character sets shall
have the following members: [...]
Faut-il comprendre le "shall have" comme un "shall have only" ou un
"shall have at least". Dans la langue courante, ce serait un "shall
have at least", mais qu'en est-il de l'interprétation de la norme?
Dans l'article <c5lg7q$5vd$,
Antoine Leca écrit:On ne doit pas avoir la même manière de lire...
« N'importe quel compilateur », c'est clairement à mon sens
l'obligation de ne pas dépendre du compilateur. Donc de ne pas
s'intéresser aux particularités de tel ou tel.
Non, justement s'il veut pouvoir compiler avec n'importe quel
compilateur, il faut s'intéresser aux particularités de tous
les compilateurs
(sous réserve que celles-ci "respectent la
norme"), tout comme il ne faut pas supposer que int, long et
long long aient telle ou telle taille (cf discussion récente
sur le fait que Microsoft utilisait des tailles particulières).
Dans la norme, c'est tellement défini à l'avance que cela l'est
avant même le début de la compilation: ce codage est « défini par
l'implémentation », ce qui signifie que le fournisseur du
compilateur est obligé de le préciser dans la documentation.
En tout cas, ce n'est pas le cas avec gcc.
éventuellement a sur des systèmes non POSIX).
D'accord qu'il y ait une différence si tu ne considères que le jeu de
base. Mais cela n'empêche que c'est *dépendant de l'implémentation*.
Tu obtiendras toujours un 'a', mais son code est dépend de
l'implémentation.
[3] Both the basic source and basic execution character sets shall
have the following members: [...]
Faut-il comprendre le "shall have" comme un "shall have only" ou un
"shall have at least". Dans la langue courante, ce serait un "shall
have at least", mais qu'en est-il de l'interprétation de la norme?
En 20040415121812$, Vincent Lefevre va escriure:Non, justement s'il veut pouvoir compiler avec n'importe quel
compilateur, il faut s'intéresser aux particularités de tous
les compilateurs
Non. Il faut les fuir, au contraire !
(sous réserve que celles-ci "respectent la
norme"), tout comme il ne faut pas supposer que int, long et
long long aient telle ou telle taille (cf discussion récente
sur le fait que Microsoft utilisait des tailles particulières).
Là oui. Il faut éviter de _dépendre_ des particularités. En fait, il
*ne*faut*pas* dépendre des particularités.
Dans la norme, c'est tellement défini à l'avance que cela l'est
avant même le début de la compilation: ce codage est « défini par
l'implémentation », ce qui signifie que le fournisseur du
compilateur est obligé de le préciser dans la documentation.
En tout cas, ce n'est pas le cas avec gcc.
Cela doit l'être, je ne penses pas que GCC C ait une telle
disconformité.
Pour GCC C, cela doit dire quelque chose comme "les caractères sont
encodés suivant l'encodage utilisé pour le fichier source".
Je rappelle que "dépendant de l'implémentation", dans le texte de la
norme, cela sert à signaler les points où le résultat n'est pas
déterministe *avec le seul texte de la norme*, mais qu'il est *en
utilisant la documentation de l'implémentation*.
En l'occurence, il est évident que le flux d'électrons émis par
HelloWorld.c va être différent suivant si tu es sur un mainframe IBM
ou un PC. Mais la documentation de ton compilateur va te le dire.
Et un 'a' sera toujours un 'a', ce n'est pas le fait que ce soit
codé 0201 ou 61 (les deux seules options pratiques) qui va rendre le
programme non conforme au sens strict.
En 20040415121812$4fb6@vinc17.org, Vincent Lefevre va escriure:
Non, justement s'il veut pouvoir compiler avec n'importe quel
compilateur, il faut s'intéresser aux particularités de tous
les compilateurs
Non. Il faut les fuir, au contraire !
(sous réserve que celles-ci "respectent la
norme"), tout comme il ne faut pas supposer que int, long et
long long aient telle ou telle taille (cf discussion récente
sur le fait que Microsoft utilisait des tailles particulières).
Là oui. Il faut éviter de _dépendre_ des particularités. En fait, il
*ne*faut*pas* dépendre des particularités.
Dans la norme, c'est tellement défini à l'avance que cela l'est
avant même le début de la compilation: ce codage est « défini par
l'implémentation », ce qui signifie que le fournisseur du
compilateur est obligé de le préciser dans la documentation.
En tout cas, ce n'est pas le cas avec gcc.
Cela doit l'être, je ne penses pas que GCC C ait une telle
disconformité.
Pour GCC C, cela doit dire quelque chose comme "les caractères sont
encodés suivant l'encodage utilisé pour le fichier source".
Je rappelle que "dépendant de l'implémentation", dans le texte de la
norme, cela sert à signaler les points où le résultat n'est pas
déterministe *avec le seul texte de la norme*, mais qu'il est *en
utilisant la documentation de l'implémentation*.
En l'occurence, il est évident que le flux d'électrons émis par
HelloWorld.c va être différent suivant si tu es sur un mainframe IBM
ou un PC. Mais la documentation de ton compilateur va te le dire.
Et un 'a' sera toujours un 'a', ce n'est pas le fait que ce soit
codé 0201 ou 61 (les deux seules options pratiques) qui va rendre le
programme non conforme au sens strict.
En 20040415121812$, Vincent Lefevre va escriure:Non, justement s'il veut pouvoir compiler avec n'importe quel
compilateur, il faut s'intéresser aux particularités de tous
les compilateurs
Non. Il faut les fuir, au contraire !
(sous réserve que celles-ci "respectent la
norme"), tout comme il ne faut pas supposer que int, long et
long long aient telle ou telle taille (cf discussion récente
sur le fait que Microsoft utilisait des tailles particulières).
Là oui. Il faut éviter de _dépendre_ des particularités. En fait, il
*ne*faut*pas* dépendre des particularités.
Dans la norme, c'est tellement défini à l'avance que cela l'est
avant même le début de la compilation: ce codage est « défini par
l'implémentation », ce qui signifie que le fournisseur du
compilateur est obligé de le préciser dans la documentation.
En tout cas, ce n'est pas le cas avec gcc.
Cela doit l'être, je ne penses pas que GCC C ait une telle
disconformité.
Pour GCC C, cela doit dire quelque chose comme "les caractères sont
encodés suivant l'encodage utilisé pour le fichier source".
Je rappelle que "dépendant de l'implémentation", dans le texte de la
norme, cela sert à signaler les points où le résultat n'est pas
déterministe *avec le seul texte de la norme*, mais qu'il est *en
utilisant la documentation de l'implémentation*.
En l'occurence, il est évident que le flux d'électrons émis par
HelloWorld.c va être différent suivant si tu es sur un mainframe IBM
ou un PC. Mais la documentation de ton compilateur va te le dire.
Et un 'a' sera toujours un 'a', ce n'est pas le fait que ce soit
codé 0201 ou 61 (les deux seules options pratiques) qui va rendre le
programme non conforme au sens strict.
Dans l'article <c5mhhf$lsm$,
Antoine Leca écrit:Pour GCC C, cela doit dire quelque chose comme "les caractères sont
encodés suivant l'encodage utilisé pour le fichier source".
Suivant l'encodage utilisé, on n'aura pas le même binaire, donc pas le
même comportement à l'exécution.
En l'occurence, il est évident que le flux d'électrons émis par
HelloWorld.c va être différent suivant si tu es sur un mainframe IBM
ou un PC. Mais la documentation de ton compilateur va te le dire.
Elle va le dire, mais le résultat est tout de même dépendant de
l'implémentation.
Et un 'a' sera toujours un 'a', ce n'est pas le fait que ce soit
codé 0201 ou 61 (les deux seules options pratiques) qui va rendre le
programme non conforme au sens strict.
Le résultat est pourtant dépendant de l'implémentation, à moins que
tu considéres que l'encodage n'a aucune importance, ce qui est osé
(on peut au contraire vouloir des données binaires fixes).
Dans l'article <c5mhhf$lsm$1@shakotay.alphanet.ch>,
Antoine Leca <root@localhost.gov> écrit:
Pour GCC C, cela doit dire quelque chose comme "les caractères sont
encodés suivant l'encodage utilisé pour le fichier source".
Suivant l'encodage utilisé, on n'aura pas le même binaire, donc pas le
même comportement à l'exécution.
En l'occurence, il est évident que le flux d'électrons émis par
HelloWorld.c va être différent suivant si tu es sur un mainframe IBM
ou un PC. Mais la documentation de ton compilateur va te le dire.
Elle va le dire, mais le résultat est tout de même dépendant de
l'implémentation.
Et un 'a' sera toujours un 'a', ce n'est pas le fait que ce soit
codé 0201 ou 61 (les deux seules options pratiques) qui va rendre le
programme non conforme au sens strict.
Le résultat est pourtant dépendant de l'implémentation, à moins que
tu considéres que l'encodage n'a aucune importance, ce qui est osé
(on peut au contraire vouloir des données binaires fixes).
Dans l'article <c5mhhf$lsm$,
Antoine Leca écrit:Pour GCC C, cela doit dire quelque chose comme "les caractères sont
encodés suivant l'encodage utilisé pour le fichier source".
Suivant l'encodage utilisé, on n'aura pas le même binaire, donc pas le
même comportement à l'exécution.
En l'occurence, il est évident que le flux d'électrons émis par
HelloWorld.c va être différent suivant si tu es sur un mainframe IBM
ou un PC. Mais la documentation de ton compilateur va te le dire.
Elle va le dire, mais le résultat est tout de même dépendant de
l'implémentation.
Et un 'a' sera toujours un 'a', ce n'est pas le fait que ce soit
codé 0201 ou 61 (les deux seules options pratiques) qui va rendre le
programme non conforme au sens strict.
Le résultat est pourtant dépendant de l'implémentation, à moins que
tu considéres que l'encodage n'a aucune importance, ce qui est osé
(on peut au contraire vouloir des données binaires fixes).
En 20040415202425$, Vincent Lefevre va escriure:Dans l'article <c5mhhf$lsm$,
Antoine Leca écrit:Pour GCC C, cela doit dire quelque chose comme "les caractères sont
encodés suivant l'encodage utilisé pour le fichier source".
Suivant l'encodage utilisé, on n'aura pas le même binaire, donc pas le
même comportement à l'exécution.
Oui (pour les caractères hors du jeu de base). Et ce rend donc les
programmes non strictement conformes.
Si tu veux des données binaires fixes, tu n'écriras pas 'a', tu écrirais
'x61' ou '201', suivant les cas.
En 20040415202425$21bf@vinc17.org, Vincent Lefevre va escriure:
Dans l'article <c5mhhf$lsm$1@shakotay.alphanet.ch>,
Antoine Leca <root@localhost.gov> écrit:
Pour GCC C, cela doit dire quelque chose comme "les caractères sont
encodés suivant l'encodage utilisé pour le fichier source".
Suivant l'encodage utilisé, on n'aura pas le même binaire, donc pas le
même comportement à l'exécution.
Oui (pour les caractères hors du jeu de base). Et ce rend donc les
programmes non strictement conformes.
Si tu veux des données binaires fixes, tu n'écriras pas 'a', tu écrirais
'x61' ou '201', suivant les cas.
En 20040415202425$, Vincent Lefevre va escriure:Dans l'article <c5mhhf$lsm$,
Antoine Leca écrit:Pour GCC C, cela doit dire quelque chose comme "les caractères sont
encodés suivant l'encodage utilisé pour le fichier source".
Suivant l'encodage utilisé, on n'aura pas le même binaire, donc pas le
même comportement à l'exécution.
Oui (pour les caractères hors du jeu de base). Et ce rend donc les
programmes non strictement conformes.
Si tu veux des données binaires fixes, tu n'écriras pas 'a', tu écrirais
'x61' ou '201', suivant les cas.
Oui (pour les caractères hors du jeu de base). Et ce rend donc les
programmes non strictement conformes.
Même pour les caractères du jeu de base.
Si tu veux des données binaires fixes, tu n'écriras pas 'a', tu
écrirais 'x61' ou '201', suivant les cas.
Cela tombe sous le sens. Mais ce n'est pas explicitement dit par la
norme.
Imagine qu'un programmeur veuille générer un caractère 'a' pour
l'implémentation (de manière portable), compile son programme. Puis il
décide plus tard d'utiliser le résultat dans un contexte où le jeu de
caractères est basé sur l'ASCII. Suivant les implémentations, on aura
bien des différences, et le programme est non strictement conforme.
La norme ne présuppose pas que ce que le programmeur a écrit est
exactement ce qu'il veut.
En particulier, si le programmeur écrit
'a', la norme ne présuppose pas que le programmeur veut un 'a' en
sortie sans s'intéresser à l'encodage.
Si le programmeur veut un
encodage particulier alors qu'il utilise 'a'
Oui (pour les caractères hors du jeu de base). Et ce rend donc les
programmes non strictement conformes.
Même pour les caractères du jeu de base.
Si tu veux des données binaires fixes, tu n'écriras pas 'a', tu
écrirais 'x61' ou '201', suivant les cas.
Cela tombe sous le sens. Mais ce n'est pas explicitement dit par la
norme.
Imagine qu'un programmeur veuille générer un caractère 'a' pour
l'implémentation (de manière portable), compile son programme. Puis il
décide plus tard d'utiliser le résultat dans un contexte où le jeu de
caractères est basé sur l'ASCII. Suivant les implémentations, on aura
bien des différences, et le programme est non strictement conforme.
La norme ne présuppose pas que ce que le programmeur a écrit est
exactement ce qu'il veut.
En particulier, si le programmeur écrit
'a', la norme ne présuppose pas que le programmeur veut un 'a' en
sortie sans s'intéresser à l'encodage.
Si le programmeur veut un
encodage particulier alors qu'il utilise 'a'
Oui (pour les caractères hors du jeu de base). Et ce rend donc les
programmes non strictement conformes.
Même pour les caractères du jeu de base.
Si tu veux des données binaires fixes, tu n'écriras pas 'a', tu
écrirais 'x61' ou '201', suivant les cas.
Cela tombe sous le sens. Mais ce n'est pas explicitement dit par la
norme.
Imagine qu'un programmeur veuille générer un caractère 'a' pour
l'implémentation (de manière portable), compile son programme. Puis il
décide plus tard d'utiliser le résultat dans un contexte où le jeu de
caractères est basé sur l'ASCII. Suivant les implémentations, on aura
bien des différences, et le programme est non strictement conforme.
La norme ne présuppose pas que ce que le programmeur a écrit est
exactement ce qu'il veut.
En particulier, si le programmeur écrit
'a', la norme ne présuppose pas que le programmeur veut un 'a' en
sortie sans s'intéresser à l'encodage.
Si le programmeur veut un
encodage particulier alors qu'il utilise 'a'
En 20040416165446$, Vincent Lefevre va escriure:Oui (pour les caractères hors du jeu de base). Et ce rend donc les
programmes non strictement conformes.
Même pour les caractères du jeu de base.
Pas d'accord.
Prenons une chaîne de spécifications de fprintf. Elle est définie par des
constantes caractères. Qui sont stockées dans le binaire (et on ne peut
envisager un mécanisme spécifique, puisque c'est un argument comme les
autres, il peut être variable).
Si tu veux des données binaires fixes, tu n'écriras pas 'a', tu
écrirais 'x61' ou '201', suivant les cas.
Cela tombe sous le sens. Mais ce n'est pas explicitement dit par la
norme.
Ah non ? Et où la norme expliquerait le contraire ?
Parce que les normes ISO disent bien clairement que ce qui n'est pas
défini explicitement doit être compris avec l'acceptation commune
(du OED pour le sens des mots). Donc si cela tombe sous le sens, et
que la norme ne dit pas le contraire, c'est comme cela qu'il faut
faire, et pas inventer autre chose.
Imagine qu'un programmeur veuille générer un caractère 'a' pour
l'implémentation (de manière portable), compile son programme. Puis il
décide plus tard d'utiliser le résultat dans un contexte où le jeu de
caractères est basé sur l'ASCII. Suivant les implémentations, on aura
bien des différences, et le programme est non strictement conforme.
Je n'ai toujours pas compris pourquoi il y aurait des différences.
Soit il a compilé pour une cible ASCII. Le programme focntionne, et
fonctionne toujours de la même manière. Aucune différence.
Soit il a compilé pour une cible EBCDIC. Clairement, s'il utilise le binaire
sur une machine qui marche en ASCII, il n'a pas utilisé un enviroenement de
compilation conforme, c'est tout. Parce que en l'occurence, RIEN ne marche.
La norme ne présuppose pas que ce que le programmeur a écrit est
exactement ce qu'il veut.
D'accord.En particulier, si le programmeur écrit 'a', la norme ne
présuppose pas que le programmeur veut un 'a' en sortie sans
s'intéresser à l'encodage.
Si. Parce que la norme ne définit à aucun endroit cet encodage (sauf
pour les chiffres décimaux). Elle ne définit que des propriétés
minimales de cet encodage, comme le fait qu'il doit être entre 1 et
CHAR_MAX, ou l'effet des "format effectors".
Si le programmeur veut un
encodage particulier alors qu'il utilise 'a'
... alors il n'utilise pas le bon outil ! La norme ne lui donne pas cette
possibilité, c'est tout. Ou plus exactement, son programme n'est _plus_
strictement conforme.
En 20040416165446$4af3@vinc17.org, Vincent Lefevre va escriure:
Oui (pour les caractères hors du jeu de base). Et ce rend donc les
programmes non strictement conformes.
Même pour les caractères du jeu de base.
Pas d'accord.
Prenons une chaîne de spécifications de fprintf. Elle est définie par des
constantes caractères. Qui sont stockées dans le binaire (et on ne peut
envisager un mécanisme spécifique, puisque c'est un argument comme les
autres, il peut être variable).
Si tu veux des données binaires fixes, tu n'écriras pas 'a', tu
écrirais 'x61' ou '201', suivant les cas.
Cela tombe sous le sens. Mais ce n'est pas explicitement dit par la
norme.
Ah non ? Et où la norme expliquerait le contraire ?
Parce que les normes ISO disent bien clairement que ce qui n'est pas
défini explicitement doit être compris avec l'acceptation commune
(du OED pour le sens des mots). Donc si cela tombe sous le sens, et
que la norme ne dit pas le contraire, c'est comme cela qu'il faut
faire, et pas inventer autre chose.
Imagine qu'un programmeur veuille générer un caractère 'a' pour
l'implémentation (de manière portable), compile son programme. Puis il
décide plus tard d'utiliser le résultat dans un contexte où le jeu de
caractères est basé sur l'ASCII. Suivant les implémentations, on aura
bien des différences, et le programme est non strictement conforme.
Je n'ai toujours pas compris pourquoi il y aurait des différences.
Soit il a compilé pour une cible ASCII. Le programme focntionne, et
fonctionne toujours de la même manière. Aucune différence.
Soit il a compilé pour une cible EBCDIC. Clairement, s'il utilise le binaire
sur une machine qui marche en ASCII, il n'a pas utilisé un enviroenement de
compilation conforme, c'est tout. Parce que en l'occurence, RIEN ne marche.
La norme ne présuppose pas que ce que le programmeur a écrit est
exactement ce qu'il veut.
D'accord.
En particulier, si le programmeur écrit 'a', la norme ne
présuppose pas que le programmeur veut un 'a' en sortie sans
s'intéresser à l'encodage.
Si. Parce que la norme ne définit à aucun endroit cet encodage (sauf
pour les chiffres décimaux). Elle ne définit que des propriétés
minimales de cet encodage, comme le fait qu'il doit être entre 1 et
CHAR_MAX, ou l'effet des "format effectors".
Si le programmeur veut un
encodage particulier alors qu'il utilise 'a'
... alors il n'utilise pas le bon outil ! La norme ne lui donne pas cette
possibilité, c'est tout. Ou plus exactement, son programme n'est _plus_
strictement conforme.
En 20040416165446$, Vincent Lefevre va escriure:Oui (pour les caractères hors du jeu de base). Et ce rend donc les
programmes non strictement conformes.
Même pour les caractères du jeu de base.
Pas d'accord.
Prenons une chaîne de spécifications de fprintf. Elle est définie par des
constantes caractères. Qui sont stockées dans le binaire (et on ne peut
envisager un mécanisme spécifique, puisque c'est un argument comme les
autres, il peut être variable).
Si tu veux des données binaires fixes, tu n'écriras pas 'a', tu
écrirais 'x61' ou '201', suivant les cas.
Cela tombe sous le sens. Mais ce n'est pas explicitement dit par la
norme.
Ah non ? Et où la norme expliquerait le contraire ?
Parce que les normes ISO disent bien clairement que ce qui n'est pas
défini explicitement doit être compris avec l'acceptation commune
(du OED pour le sens des mots). Donc si cela tombe sous le sens, et
que la norme ne dit pas le contraire, c'est comme cela qu'il faut
faire, et pas inventer autre chose.
Imagine qu'un programmeur veuille générer un caractère 'a' pour
l'implémentation (de manière portable), compile son programme. Puis il
décide plus tard d'utiliser le résultat dans un contexte où le jeu de
caractères est basé sur l'ASCII. Suivant les implémentations, on aura
bien des différences, et le programme est non strictement conforme.
Je n'ai toujours pas compris pourquoi il y aurait des différences.
Soit il a compilé pour une cible ASCII. Le programme focntionne, et
fonctionne toujours de la même manière. Aucune différence.
Soit il a compilé pour une cible EBCDIC. Clairement, s'il utilise le binaire
sur une machine qui marche en ASCII, il n'a pas utilisé un enviroenement de
compilation conforme, c'est tout. Parce que en l'occurence, RIEN ne marche.
La norme ne présuppose pas que ce que le programmeur a écrit est
exactement ce qu'il veut.
D'accord.En particulier, si le programmeur écrit 'a', la norme ne
présuppose pas que le programmeur veut un 'a' en sortie sans
s'intéresser à l'encodage.
Si. Parce que la norme ne définit à aucun endroit cet encodage (sauf
pour les chiffres décimaux). Elle ne définit que des propriétés
minimales de cet encodage, comme le fait qu'il doit être entre 1 et
CHAR_MAX, ou l'effet des "format effectors".
Si le programmeur veut un
encodage particulier alors qu'il utilise 'a'
... alors il n'utilise pas le bon outil ! La norme ne lui donne pas cette
possibilité, c'est tout. Ou plus exactement, son programme n'est _plus_
strictement conforme.
Attention, je ne considère pas un binaire fixé, mais des binaires
générés par des implémentations différentes. Les caractères en
sortie seront les mêmes (pour le jeu de base), mais pas les codes
(on peut avoir de l'ASCII, de l'EBCDIC ou autre chose suivant
l'implémentation).
Pas d'accord. On peut très bien manipuler de l'EBCDIC dans un
environnement d'exécution utilisant de l'ASCII.
Ce que j'entends
par là, c'est qu'on peut très bien vouloir manipuler des codes
binaires alors qu'initialement on manipulait des caractères.
En particulier, si le programmeur écrit 'a', la norme ne
présuppose pas que le programmeur veut un 'a' en sortie sans
s'intéresser à l'encodage.
Si. Parce que la norme ne définit à aucun endroit cet encodage (sauf
pour les chiffres décimaux). Elle ne définit que des propriétés
minimales de cet encodage, comme le fait qu'il doit être entre 1 et
CHAR_MAX, ou l'effet des "format effectors".
Et alors? Je ne suis pas du tout d'accord avec ton argumentation.
Voici un exemple *utile* montrant qu'on peut très bien utiliser 'a'
à la fois sous la forme caractère et sous la forme numérique:
#include <stdio.h>
int main(void)
{
int c = 'a';
printf("Code de '%c' = %dn", c, c);
return 0;
}
J'espère que cela te convaincra.
Attention, je ne considère pas un binaire fixé, mais des binaires
générés par des implémentations différentes. Les caractères en
sortie seront les mêmes (pour le jeu de base), mais pas les codes
(on peut avoir de l'ASCII, de l'EBCDIC ou autre chose suivant
l'implémentation).
Pas d'accord. On peut très bien manipuler de l'EBCDIC dans un
environnement d'exécution utilisant de l'ASCII.
Ce que j'entends
par là, c'est qu'on peut très bien vouloir manipuler des codes
binaires alors qu'initialement on manipulait des caractères.
En particulier, si le programmeur écrit 'a', la norme ne
présuppose pas que le programmeur veut un 'a' en sortie sans
s'intéresser à l'encodage.
Si. Parce que la norme ne définit à aucun endroit cet encodage (sauf
pour les chiffres décimaux). Elle ne définit que des propriétés
minimales de cet encodage, comme le fait qu'il doit être entre 1 et
CHAR_MAX, ou l'effet des "format effectors".
Et alors? Je ne suis pas du tout d'accord avec ton argumentation.
Voici un exemple *utile* montrant qu'on peut très bien utiliser 'a'
à la fois sous la forme caractère et sous la forme numérique:
#include <stdio.h>
int main(void)
{
int c = 'a';
printf("Code de '%c' = %dn", c, c);
return 0;
}
J'espère que cela te convaincra.
Attention, je ne considère pas un binaire fixé, mais des binaires
générés par des implémentations différentes. Les caractères en
sortie seront les mêmes (pour le jeu de base), mais pas les codes
(on peut avoir de l'ASCII, de l'EBCDIC ou autre chose suivant
l'implémentation).
Pas d'accord. On peut très bien manipuler de l'EBCDIC dans un
environnement d'exécution utilisant de l'ASCII.
Ce que j'entends
par là, c'est qu'on peut très bien vouloir manipuler des codes
binaires alors qu'initialement on manipulait des caractères.
En particulier, si le programmeur écrit 'a', la norme ne
présuppose pas que le programmeur veut un 'a' en sortie sans
s'intéresser à l'encodage.
Si. Parce que la norme ne définit à aucun endroit cet encodage (sauf
pour les chiffres décimaux). Elle ne définit que des propriétés
minimales de cet encodage, comme le fait qu'il doit être entre 1 et
CHAR_MAX, ou l'effet des "format effectors".
Et alors? Je ne suis pas du tout d'accord avec ton argumentation.
Voici un exemple *utile* montrant qu'on peut très bien utiliser 'a'
à la fois sous la forme caractère et sous la forme numérique:
#include <stdio.h>
int main(void)
{
int c = 'a';
printf("Code de '%c' = %dn", c, c);
return 0;
}
J'espère que cela te convaincra.
Ce que je dis, c'est que ce qui importe, ce n'est pas le contenu du binaire
pour une plateforme donnée (qui ne fait pas partie de ce que définit la
norme), mais la signification de la suite de multiplets codée dans ce
binaire, qui doivent être les caractères (du jeu de base), '%', 's', etc.,
Le programme strictement conforme ne peut pas tirer profit des valeurs
réelles de ces codes, juste du fait qu'ils existent et qu'ils sont
distincts. C'est comme avec INT_MAX: un programme portable peut utiliser
cette valeur, par exemple pour faire des optimisations (utiliser des int au
lieu de long pour des quantités 32 bits sur un plateforme donnée), mais ne
peut pas afficher la valeur de cette constante.
Ce que j'entends par là, c'est qu'on peut très bien vouloir
manipuler des codes binaires alors qu'initialement on manipulait
des caractères.
Oui. Et la seule manière de le faire en C (strictement conforme),
c'est d'abandonner les constantes caractères (ou chaînes). Le fait
que ce ne soit pas la pratique, démontre seulement qu'à peu près
personne ne cherche à le faire.
Et alors? Je ne suis pas du tout d'accord avec ton argumentation.
Voici un exemple *utile* montrant qu'on peut très bien utiliser 'a'
à la fois sous la forme caractère et sous la forme numérique:
#include <stdio.h>
int main(void)
{
int c = 'a';
printf("Code de '%c' = %dn", c, c);
return 0;
}
J'espère que cela te convaincra.
De quoi devrais-je être convaincu ?
La seule chose qui est claire pour moi, c'est que cet exemple n'est pas
strictement conforme.
Ce que je dis, c'est que ce qui importe, ce n'est pas le contenu du binaire
pour une plateforme donnée (qui ne fait pas partie de ce que définit la
norme), mais la signification de la suite de multiplets codée dans ce
binaire, qui doivent être les caractères (du jeu de base), '%', 's', etc.,
Le programme strictement conforme ne peut pas tirer profit des valeurs
réelles de ces codes, juste du fait qu'ils existent et qu'ils sont
distincts. C'est comme avec INT_MAX: un programme portable peut utiliser
cette valeur, par exemple pour faire des optimisations (utiliser des int au
lieu de long pour des quantités 32 bits sur un plateforme donnée), mais ne
peut pas afficher la valeur de cette constante.
Ce que j'entends par là, c'est qu'on peut très bien vouloir
manipuler des codes binaires alors qu'initialement on manipulait
des caractères.
Oui. Et la seule manière de le faire en C (strictement conforme),
c'est d'abandonner les constantes caractères (ou chaînes). Le fait
que ce ne soit pas la pratique, démontre seulement qu'à peu près
personne ne cherche à le faire.
Et alors? Je ne suis pas du tout d'accord avec ton argumentation.
Voici un exemple *utile* montrant qu'on peut très bien utiliser 'a'
à la fois sous la forme caractère et sous la forme numérique:
#include <stdio.h>
int main(void)
{
int c = 'a';
printf("Code de '%c' = %dn", c, c);
return 0;
}
J'espère que cela te convaincra.
De quoi devrais-je être convaincu ?
La seule chose qui est claire pour moi, c'est que cet exemple n'est pas
strictement conforme.
Ce que je dis, c'est que ce qui importe, ce n'est pas le contenu du binaire
pour une plateforme donnée (qui ne fait pas partie de ce que définit la
norme), mais la signification de la suite de multiplets codée dans ce
binaire, qui doivent être les caractères (du jeu de base), '%', 's', etc.,
Le programme strictement conforme ne peut pas tirer profit des valeurs
réelles de ces codes, juste du fait qu'ils existent et qu'ils sont
distincts. C'est comme avec INT_MAX: un programme portable peut utiliser
cette valeur, par exemple pour faire des optimisations (utiliser des int au
lieu de long pour des quantités 32 bits sur un plateforme donnée), mais ne
peut pas afficher la valeur de cette constante.
Ce que j'entends par là, c'est qu'on peut très bien vouloir
manipuler des codes binaires alors qu'initialement on manipulait
des caractères.
Oui. Et la seule manière de le faire en C (strictement conforme),
c'est d'abandonner les constantes caractères (ou chaînes). Le fait
que ce ne soit pas la pratique, démontre seulement qu'à peu près
personne ne cherche à le faire.
Et alors? Je ne suis pas du tout d'accord avec ton argumentation.
Voici un exemple *utile* montrant qu'on peut très bien utiliser 'a'
à la fois sous la forme caractère et sous la forme numérique:
#include <stdio.h>
int main(void)
{
int c = 'a';
printf("Code de '%c' = %dn", c, c);
return 0;
}
J'espère que cela te convaincra.
De quoi devrais-je être convaincu ?
La seule chose qui est claire pour moi, c'est que cet exemple n'est pas
strictement conforme.
Dans l'article <c62v7i$t6q$,
Antoine Leca écrit:Ce que je dis, c'est que ce qui importe, ce n'est pas le contenu du
binaire pour une plateforme donnée (qui ne fait pas partie de ce que
définit la norme), mais la signification de la suite de multiplets
codée dans ce binaire, qui doivent être les caractères (du jeu de
base), '%', 's', etc.,
Je pense que c'est notre point de désaccord. Je ne vois pas pourquoi
le contenu du binaire ne serait pas important (pour l'ensemble des
applications possibles) et ne devrait donc pas être pris en compte.
Juste pour savoir... En admettant ton interprétation, est-ce que le
programme suivant est strictement conforme?
#include <stdio.h>
int main(void)
{
printf ("%dn", INT_MAX == 32767 ? INT_MAX : 32767);
return 0;
}
Mais pourtant ces codes binaires auront une interprétation différente
suivant les implémentation. Donc pourquoi serait-ce strictement
conforme?
De quoi devrais-je être convaincu ?
La seule chose qui est claire pour moi, c'est que cet exemple n'est
pas strictement conforme.
Pourquoi dis-tu cela sur ce programme alors que tu réfutes
l'utilisation des codes binaires plus haut?
Dans l'article <c62v7i$t6q$1@shakotay.alphanet.ch>,
Antoine Leca <root@localhost.gov> écrit:
Ce que je dis, c'est que ce qui importe, ce n'est pas le contenu du
binaire pour une plateforme donnée (qui ne fait pas partie de ce que
définit la norme), mais la signification de la suite de multiplets
codée dans ce binaire, qui doivent être les caractères (du jeu de
base), '%', 's', etc.,
Je pense que c'est notre point de désaccord. Je ne vois pas pourquoi
le contenu du binaire ne serait pas important (pour l'ensemble des
applications possibles) et ne devrait donc pas être pris en compte.
Juste pour savoir... En admettant ton interprétation, est-ce que le
programme suivant est strictement conforme?
#include <stdio.h>
int main(void)
{
printf ("%dn", INT_MAX == 32767 ? INT_MAX : 32767);
return 0;
}
Mais pourtant ces codes binaires auront une interprétation différente
suivant les implémentation. Donc pourquoi serait-ce strictement
conforme?
De quoi devrais-je être convaincu ?
La seule chose qui est claire pour moi, c'est que cet exemple n'est
pas strictement conforme.
Pourquoi dis-tu cela sur ce programme alors que tu réfutes
l'utilisation des codes binaires plus haut?
Dans l'article <c62v7i$t6q$,
Antoine Leca écrit:Ce que je dis, c'est que ce qui importe, ce n'est pas le contenu du
binaire pour une plateforme donnée (qui ne fait pas partie de ce que
définit la norme), mais la signification de la suite de multiplets
codée dans ce binaire, qui doivent être les caractères (du jeu de
base), '%', 's', etc.,
Je pense que c'est notre point de désaccord. Je ne vois pas pourquoi
le contenu du binaire ne serait pas important (pour l'ensemble des
applications possibles) et ne devrait donc pas être pris en compte.
Juste pour savoir... En admettant ton interprétation, est-ce que le
programme suivant est strictement conforme?
#include <stdio.h>
int main(void)
{
printf ("%dn", INT_MAX == 32767 ? INT_MAX : 32767);
return 0;
}
Mais pourtant ces codes binaires auront une interprétation différente
suivant les implémentation. Donc pourquoi serait-ce strictement
conforme?
De quoi devrais-je être convaincu ?
La seule chose qui est claire pour moi, c'est que cet exemple n'est
pas strictement conforme.
Pourquoi dis-tu cela sur ce programme alors que tu réfutes
l'utilisation des codes binaires plus haut?