Un collègue m'a posé une question à laquelle je fus incapable de
répondre : si on suit strictement la norme ISO C90 est-on garanti
d'avoir un programme portable partout ?
Par 'portable partout' j'entends que le programme compilé par n'importe
quel compilateur (respectant la norme) sur n'importe quelle architecture
donne le même résultat (aux erreurs de précision numérique et aux bugs
du compilateur près).
La véritable question est en fait de savoir si la norme est suffisante
ou bien s'il y a des lacunes dedans pour garantir qu'un programme sera
portable.
Si la norme ne suffit pas, pourriez-vous m'indiquer un sous-ensemble de
la norme pouvant garantir la portabilité ?
à mon sens, oui : il produit toujours "32767n", donc peut être réduit à int main() { puts("32767"); return 0;} C'est juste une variante de HelloWorld.c, et l'idée c'est bien que ce programme-là, au moins, soit strictement conforme. Je sers du fait que c'est le résultat qui compte, pas la manière d'y arriver. Donc pour reprendre ton exemple,
#include <stdio.h> #include <limits.h> int main(void) { int c = 'a'; char s[CHAR_BIT/3 + 17]; sprintf(s, "Code de '%c' = %dn", c, c); return 0; }
est, à mon sens, strictement conforme. Y compris si on rajoute un appel à setlocale(LC_CTYPE, "");.
D'accord, puisqu'on ne sort rien.
[ En fait, il ne l'est pas, parce que, théoriquement, CHAR_BIT peut être très grand, et alors soit s va passer la limite de 32767/65535, soit le %d va dépasser la limite de 509/4095. Mais bon. ]
Pas regardé en détail, mais je vois ce que tu veux dire.
Mais pourtant ces codes binaires auront une interprétation différente suivant les implémentation. Donc pourquoi serait-ce strictement conforme?
Justement, c'est là le point: si tu interprètes les codes binaires, tu sors de la conformité stricte.
C'est justement mon point de vue. L'utilisateur peut *toujours* interpréter les codes binaires, même si ce n'est pas la volonté du programmeur. Le fait est que ça dépend de l'implémentation.
[...]
Parce que avec ton programme, une machine ASCII va donner Code de 'a' = 97<NL> Et une machine EBCDIC Code de 'a' = 129<NL> Ce qui n'est pas la même chose, donc le programme n'a pas le même effet sur deux machines différentes, donc il n'est pas portable au sens où l'effet du programme doit être identique.
Et pourtant, le programme sort la même information que si on envoyait 'a' en sortie: l'utilisateur peut très bien regarder le code binaire de 'a' derrière.
-- Vincent Lefèvre - Web: <http://www.vinc17.org/> 100% validated (X)HTML - Acorn / RISC OS / ARM, free software, YP17, Championnat International des Jeux Mathématiques et Logiques, etc. Work: CR INRIA - computer arithmetic / SPACES project at LORIA
Dans l'article <c636m7$r76$1@shakotay.alphanet.ch>,
Antoine Leca <root@localhost.gov> écrit:
Juste pour savoir... En admettant ton interprétation, est-ce que le
programme suivant est strictement conforme?
à mon sens, oui : il
produit toujours "32767n", donc peut être réduit à
int main() { puts("32767"); return 0;}
C'est juste une variante de HelloWorld.c, et l'idée c'est bien que ce
programme-là, au moins, soit strictement conforme. Je sers du fait que c'est
le résultat qui compte, pas la manière d'y arriver. Donc pour reprendre ton
exemple,
#include <stdio.h>
#include <limits.h>
int main(void) {
int c = 'a';
char s[CHAR_BIT/3 + 17];
sprintf(s, "Code de '%c' = %dn", c, c);
return 0;
}
est, à mon sens, strictement conforme. Y compris si on rajoute un appel à
setlocale(LC_CTYPE, "");.
D'accord, puisqu'on ne sort rien.
[ En fait, il ne l'est pas, parce que, théoriquement, CHAR_BIT peut être
très grand, et alors soit s va passer la limite de 32767/65535, soit le %d
va dépasser la limite de 509/4095. Mais bon. ]
Pas regardé en détail, mais je vois ce que tu veux dire.
Mais pourtant ces codes binaires auront une interprétation différente
suivant les implémentation. Donc pourquoi serait-ce strictement
conforme?
Justement, c'est là le point: si tu interprètes les codes binaires,
tu sors de la conformité stricte.
C'est justement mon point de vue. L'utilisateur peut *toujours*
interpréter les codes binaires, même si ce n'est pas la volonté
du programmeur. Le fait est que ça dépend de l'implémentation.
[...]
Parce que avec ton programme, une machine ASCII va donner
Code de 'a' = 97<NL>
Et une machine EBCDIC
Code de 'a' = 129<NL>
Ce qui n'est pas la même chose, donc le programme n'a pas le même effet sur
deux machines différentes, donc il n'est pas portable au sens où l'effet du
programme doit être identique.
Et pourtant, le programme sort la même information que si on
envoyait 'a' en sortie: l'utilisateur peut très bien regarder
le code binaire de 'a' derrière.
--
Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/>
100% validated (X)HTML - Acorn / RISC OS / ARM, free software, YP17,
Championnat International des Jeux Mathématiques et Logiques, etc.
Work: CR INRIA - computer arithmetic / SPACES project at LORIA
à mon sens, oui : il produit toujours "32767n", donc peut être réduit à int main() { puts("32767"); return 0;} C'est juste une variante de HelloWorld.c, et l'idée c'est bien que ce programme-là, au moins, soit strictement conforme. Je sers du fait que c'est le résultat qui compte, pas la manière d'y arriver. Donc pour reprendre ton exemple,
#include <stdio.h> #include <limits.h> int main(void) { int c = 'a'; char s[CHAR_BIT/3 + 17]; sprintf(s, "Code de '%c' = %dn", c, c); return 0; }
est, à mon sens, strictement conforme. Y compris si on rajoute un appel à setlocale(LC_CTYPE, "");.
D'accord, puisqu'on ne sort rien.
[ En fait, il ne l'est pas, parce que, théoriquement, CHAR_BIT peut être très grand, et alors soit s va passer la limite de 32767/65535, soit le %d va dépasser la limite de 509/4095. Mais bon. ]
Pas regardé en détail, mais je vois ce que tu veux dire.
Mais pourtant ces codes binaires auront une interprétation différente suivant les implémentation. Donc pourquoi serait-ce strictement conforme?
Justement, c'est là le point: si tu interprètes les codes binaires, tu sors de la conformité stricte.
C'est justement mon point de vue. L'utilisateur peut *toujours* interpréter les codes binaires, même si ce n'est pas la volonté du programmeur. Le fait est que ça dépend de l'implémentation.
[...]
Parce que avec ton programme, une machine ASCII va donner Code de 'a' = 97<NL> Et une machine EBCDIC Code de 'a' = 129<NL> Ce qui n'est pas la même chose, donc le programme n'a pas le même effet sur deux machines différentes, donc il n'est pas portable au sens où l'effet du programme doit être identique.
Et pourtant, le programme sort la même information que si on envoyait 'a' en sortie: l'utilisateur peut très bien regarder le code binaire de 'a' derrière.
-- Vincent Lefèvre - Web: <http://www.vinc17.org/> 100% validated (X)HTML - Acorn / RISC OS / ARM, free software, YP17, Championnat International des Jeux Mathématiques et Logiques, etc. Work: CR INRIA - computer arithmetic / SPACES project at LORIA
