La portabilité est tout relative. En général, on suppose tout de
même que l'implémentation se comporte de manière "raisonnable".
Bon du coup je suis un peu perdu là (il est grand temps d'aller
dormir!), que dois-je répondre à mon collègue ?
- "Un programme codé en ISO C90 est-il portable ?"
S'il évite les comportements indéfinis et dépendants de
l'implémentation, oui, au sens de la norme. Mais cela ne veut pas dire
qu'il n'y aura pas de problème en pratique, à cause de bugs de
compilo, etc.
Il ne faut pas non plus qu'il écrive quelque chose du genre a//**/b,
car ça ne passe pas en C99. Mais bon, ça m'étonnerait qu'on écrive ce
genre de choses habituellement...
La portabilité est tout relative. En général, on suppose tout de
même que l'implémentation se comporte de manière "raisonnable".
Bon du coup je suis un peu perdu là (il est grand temps d'aller
dormir!), que dois-je répondre à mon collègue ?
- "Un programme codé en ISO C90 est-il portable ?"
S'il évite les comportements indéfinis et dépendants de
l'implémentation, oui, au sens de la norme. Mais cela ne veut pas dire
qu'il n'y aura pas de problème en pratique, à cause de bugs de
compilo, etc.
Il ne faut pas non plus qu'il écrive quelque chose du genre a//**/b,
car ça ne passe pas en C99. Mais bon, ça m'étonnerait qu'on écrive ce
genre de choses habituellement...
La portabilité est tout relative. En général, on suppose tout de
même que l'implémentation se comporte de manière "raisonnable".
Bon du coup je suis un peu perdu là (il est grand temps d'aller
dormir!), que dois-je répondre à mon collègue ?
- "Un programme codé en ISO C90 est-il portable ?"
S'il évite les comportements indéfinis et dépendants de
l'implémentation, oui, au sens de la norme. Mais cela ne veut pas dire
qu'il n'y aura pas de problème en pratique, à cause de bugs de
compilo, etc.
Il ne faut pas non plus qu'il écrive quelque chose du genre a//**/b,
car ça ne passe pas en C99. Mais bon, ça m'étonnerait qu'on écrive ce
genre de choses habituellement...
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 ?
Hello,
nous produisons des programmes en C, qui tournent en production
24h/24h, 7j/7j, dans de grandes banques. Nos programmes, écrit
dans un strict respect de la norme, compilent et s'éxécutent sur NT,
Linux, IBM AIX, SUN solaris, HP, VAX VMS et sur mainframe IBM, sous
OS 390 et sous Z/Os (ici nous sommes en EBCDIC). Nous faisons
énormémen d'entrés sorties (et pas seulement en texte, en binaire
aussi) et le source des programmes est le même pour chaque
client/plateforme.
Evidemmment, nous avons dans les headers quelques
directives de compilation ou d'inclusion conditionnelle. Par exemple,
pour désigner le retour chariot, tous les modules utilisent la
constante HEXA_CR, et celle ci est définie dans un .h avec la valeur
adéquate en fonction de la plateforme.
Pour les entrés sorties, y compris en binaire, tout va bien tant que
les données
sont écrites et lues sur la même plateforme.
La réponse est donc oui, un programme écrit convenablement, qui ne
fait pas de présuppositions sur tel ou tel comportement dans les cas
non définis par la norme
fonctionne sur n'importe quel OS, en tout cas sur ceux que je viens de
nommer.
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 ?
Hello,
nous produisons des programmes en C, qui tournent en production
24h/24h, 7j/7j, dans de grandes banques. Nos programmes, écrit
dans un strict respect de la norme, compilent et s'éxécutent sur NT,
Linux, IBM AIX, SUN solaris, HP, VAX VMS et sur mainframe IBM, sous
OS 390 et sous Z/Os (ici nous sommes en EBCDIC). Nous faisons
énormémen d'entrés sorties (et pas seulement en texte, en binaire
aussi) et le source des programmes est le même pour chaque
client/plateforme.
Evidemmment, nous avons dans les headers quelques
directives de compilation ou d'inclusion conditionnelle. Par exemple,
pour désigner le retour chariot, tous les modules utilisent la
constante HEXA_CR, et celle ci est définie dans un .h avec la valeur
adéquate en fonction de la plateforme.
Pour les entrés sorties, y compris en binaire, tout va bien tant que
les données
sont écrites et lues sur la même plateforme.
La réponse est donc oui, un programme écrit convenablement, qui ne
fait pas de présuppositions sur tel ou tel comportement dans les cas
non définis par la norme
fonctionne sur n'importe quel OS, en tout cas sur ceux que je viens de
nommer.
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 ?
Hello,
nous produisons des programmes en C, qui tournent en production
24h/24h, 7j/7j, dans de grandes banques. Nos programmes, écrit
dans un strict respect de la norme, compilent et s'éxécutent sur NT,
Linux, IBM AIX, SUN solaris, HP, VAX VMS et sur mainframe IBM, sous
OS 390 et sous Z/Os (ici nous sommes en EBCDIC). Nous faisons
énormémen d'entrés sorties (et pas seulement en texte, en binaire
aussi) et le source des programmes est le même pour chaque
client/plateforme.
Evidemmment, nous avons dans les headers quelques
directives de compilation ou d'inclusion conditionnelle. Par exemple,
pour désigner le retour chariot, tous les modules utilisent la
constante HEXA_CR, et celle ci est définie dans un .h avec la valeur
adéquate en fonction de la plateforme.
Pour les entrés sorties, y compris en binaire, tout va bien tant que
les données
sont écrites et lues sur la même plateforme.
La réponse est donc oui, un programme écrit convenablement, qui ne
fait pas de présuppositions sur tel ou tel comportement dans les cas
non définis par la norme
fonctionne sur n'importe quel OS, en tout cas sur ceux que je viens de
nommer.
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.
Le problème est que beaucoup de choses ne sont pas définies par la
norme (comportements indéfinis), ce qui peut entrainer un tas de
dysfonctionnements même si on suit la norme à la lettre. Exemple:
#include <stdio.h>
int main (void)
{
char *s = "Hello world";
s[4] = 'x';
return 0;
}
Ce code est parfaitement 'légal' (il ne brise aucune regle écrite),
mais il invoque un comportement indéfini (une chaine littérale
pourrait très bien être non modifiable), ce qui est un bug (potentiel
ou avéré).
Si la norme ne suffit pas, pourriez-vous m'indiquer un sous-ensemble
de la norme pouvant garantir la portabilité ?
Si on s'en tient strictement à ce qui est défini, c'est bon.
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.
Le problème est que beaucoup de choses ne sont pas définies par la
norme (comportements indéfinis), ce qui peut entrainer un tas de
dysfonctionnements même si on suit la norme à la lettre. Exemple:
#include <stdio.h>
int main (void)
{
char *s = "Hello world";
s[4] = 'x';
return 0;
}
Ce code est parfaitement 'légal' (il ne brise aucune regle écrite),
mais il invoque un comportement indéfini (une chaine littérale
pourrait très bien être non modifiable), ce qui est un bug (potentiel
ou avéré).
Si la norme ne suffit pas, pourriez-vous m'indiquer un sous-ensemble
de la norme pouvant garantir la portabilité ?
Si on s'en tient strictement à ce qui est défini, c'est bon.
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.
Le problème est que beaucoup de choses ne sont pas définies par la
norme (comportements indéfinis), ce qui peut entrainer un tas de
dysfonctionnements même si on suit la norme à la lettre. Exemple:
#include <stdio.h>
int main (void)
{
char *s = "Hello world";
s[4] = 'x';
return 0;
}
Ce code est parfaitement 'légal' (il ne brise aucune regle écrite),
mais il invoque un comportement indéfini (une chaine littérale
pourrait très bien être non modifiable), ce qui est un bug (potentiel
ou avéré).
Si la norme ne suffit pas, pourriez-vous m'indiquer un sous-ensemble
de la norme pouvant garantir la portabilité ?
Si on s'en tient strictement à ce qui est défini, c'est bon.
Bonjour,
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 ?
Il faut dans votre "strictement la norme ISO C90" tenir compte de ce
Par 'portable partout' j'entends que le programme compilé par n'importe
quel compilateur (respectant la norme) sur n'importe quelle architecture
Limitons nous aux architectures permettant une implémentation conforme
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.
En fait, on raisonne à l'envers. Ce sont ces comportements qui
Si la norme ne suffit pas, pourriez-vous m'indiquer un sous-ensemble de
la norme pouvant garantir la portabilité ?
Je n'ai pas de liste à proposer, mais il est clair que des fonctions
Bonjour,
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 ?
Il faut dans votre "strictement la norme ISO C90" tenir compte de ce
Par 'portable partout' j'entends que le programme compilé par n'importe
quel compilateur (respectant la norme) sur n'importe quelle architecture
Limitons nous aux architectures permettant une implémentation conforme
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.
En fait, on raisonne à l'envers. Ce sont ces comportements qui
Si la norme ne suffit pas, pourriez-vous m'indiquer un sous-ensemble de
la norme pouvant garantir la portabilité ?
Je n'ai pas de liste à proposer, mais il est clair que des fonctions
Bonjour,
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 ?
Il faut dans votre "strictement la norme ISO C90" tenir compte de ce
Par 'portable partout' j'entends que le programme compilé par n'importe
quel compilateur (respectant la norme) sur n'importe quelle architecture
Limitons nous aux architectures permettant une implémentation conforme
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.
En fait, on raisonne à l'envers. Ce sont ces comportements qui
Si la norme ne suffit pas, pourriez-vous m'indiquer un sous-ensemble de
la norme pouvant garantir la portabilité ?
Je n'ai pas de liste à proposer, mais il est clair que des fonctions
Si tu suis strictement la norme, tu ne peux pas faire grand chose,
en particulier aucune entrée-sortie.
Pour les entrées/sorties on peut fonctionner avec des fichiers textes.
Même avec les fichiers texte. La norme dit:
[#5] A strictly conforming program shall use only those
features of the language and library specified in this
International Standard.2) It shall not produce output
dependent on any unspecified, undefined, or implementation-
defined behavior, and shall not exceed any minimum
implementation limit.
Or le codage des caractères dépend de l'implémentation (ce n'est pas
forcément à base d'ASCII, tu as des implémentations en EBCDIC, par
exemple).
Pourriez-vous préciser? Je manque cruellement de machines exotiques
Si tu suis strictement la norme, tu ne peux pas faire grand chose,
en particulier aucune entrée-sortie.
Pour les entrées/sorties on peut fonctionner avec des fichiers textes.
Même avec les fichiers texte. La norme dit:
[#5] A strictly conforming program shall use only those
features of the language and library specified in this
International Standard.2) It shall not produce output
dependent on any unspecified, undefined, or implementation-
defined behavior, and shall not exceed any minimum
implementation limit.
Or le codage des caractères dépend de l'implémentation (ce n'est pas
forcément à base d'ASCII, tu as des implémentations en EBCDIC, par
exemple).
Pourriez-vous préciser? Je manque cruellement de machines exotiques
Si tu suis strictement la norme, tu ne peux pas faire grand chose,
en particulier aucune entrée-sortie.
Pour les entrées/sorties on peut fonctionner avec des fichiers textes.
Même avec les fichiers texte. La norme dit:
[#5] A strictly conforming program shall use only those
features of the language and library specified in this
International Standard.2) It shall not produce output
dependent on any unspecified, undefined, or implementation-
defined behavior, and shall not exceed any minimum
implementation limit.
Or le codage des caractères dépend de l'implémentation (ce n'est pas
forcément à base d'ASCII, tu as des implémentations en EBCDIC, par
exemple).
Pourriez-vous préciser? Je manque cruellement de machines exotiques
D'accord je pensais que la norme proscrivait l'utilisation des
comportements indéfinis ou d'instructions dont le résultat dépend de
l'implémentation (par exemples celles reposant sur le codage des réels
ou des entiers, les problèmes d'alignement des structures, etc...).
Mais apparemment je dois aussi ajouter cela à mon manuel de codage !
Merci pour la remarque concernant les problèmes de pile, je ne savais
pas qu'on pouvait avoir ce genre de problèmes...
D'accord je pensais que la norme proscrivait l'utilisation des
comportements indéfinis ou d'instructions dont le résultat dépend de
l'implémentation (par exemples celles reposant sur le codage des réels
ou des entiers, les problèmes d'alignement des structures, etc...).
Mais apparemment je dois aussi ajouter cela à mon manuel de codage !
Merci pour la remarque concernant les problèmes de pile, je ne savais
pas qu'on pouvait avoir ce genre de problèmes...
D'accord je pensais que la norme proscrivait l'utilisation des
comportements indéfinis ou d'instructions dont le résultat dépend de
l'implémentation (par exemples celles reposant sur le codage des réels
ou des entiers, les problèmes d'alignement des structures, etc...).
Mais apparemment je dois aussi ajouter cela à mon manuel de codage !
Merci pour la remarque concernant les problèmes de pile, je ne savais
pas qu'on pouvait avoir ce genre de problèmes...
Pourriez-vous préciser? Je manque cruellement de machines exotiques
(y'en a pas chez Auchan) pour faire les tests nécessaires à la
compréhension, mais il me semblait que le comportement de:
printf("Helllon");
était défini dans une implémentation hosted. C'est bien "Hello" et
passage à la ligne qui va être "sorti". Ce qui n'est pas garanti,
c'est "l'aspect" de stdout (dont l'existence est néanmoins garantie),
ni surtout que cette instruction y envoie la suite d'octets:
48 65 6C 6C 6F 0D 0A
Pourriez-vous préciser? Je manque cruellement de machines exotiques
(y'en a pas chez Auchan) pour faire les tests nécessaires à la
compréhension, mais il me semblait que le comportement de:
printf("Helllon");
était défini dans une implémentation hosted. C'est bien "Hello" et
passage à la ligne qui va être "sorti". Ce qui n'est pas garanti,
c'est "l'aspect" de stdout (dont l'existence est néanmoins garantie),
ni surtout que cette instruction y envoie la suite d'octets:
48 65 6C 6C 6F 0D 0A
Pourriez-vous préciser? Je manque cruellement de machines exotiques
(y'en a pas chez Auchan) pour faire les tests nécessaires à la
compréhension, mais il me semblait que le comportement de:
printf("Helllon");
était défini dans une implémentation hosted. C'est bien "Hello" et
passage à la ligne qui va être "sorti". Ce qui n'est pas garanti,
c'est "l'aspect" de stdout (dont l'existence est néanmoins garantie),
ni surtout que cette instruction y envoie la suite d'octets:
48 65 6C 6C 6F 0D 0A
Pour les problèmes de retours chariots, nous avons personnellement opté
pour la lecture binaire des fichiers textes. un parseur contenant en
mémoire tous les types de retour chariot de la création a ensuite été
utilisé (en pratique il ne contenait que la recherche de "n" et de
"rn").
Pour les problèmes de retours chariots, nous avons personnellement opté
pour la lecture binaire des fichiers textes. un parseur contenant en
mémoire tous les types de retour chariot de la création a ensuite été
utilisé (en pratique il ne contenait que la recherche de "n" et de
"rn").
Pour les problèmes de retours chariots, nous avons personnellement opté
pour la lecture binaire des fichiers textes. un parseur contenant en
mémoire tous les types de retour chariot de la création a ensuite été
utilisé (en pratique il ne contenait que la recherche de "n" et de
"rn").
Auriez-vous d'autres exemples de non portabilité de programmes qui
auraient dû être portables ?
Auriez-vous d'autres exemples de non portabilité de programmes qui
auraient dû être portables ?
Auriez-vous d'autres exemples de non portabilité de programmes qui
auraient dû être portables ?
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 ?
Si la norme ne suffit pas, pourriez-vous m'indiquer un sous-ensemble
de la norme pouvant garantir la portabilité ?
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 ?
Si la norme ne suffit pas, pourriez-vous m'indiquer un sous-ensemble
de la norme pouvant garantir la portabilité ?
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 ?
Si la norme ne suffit pas, pourriez-vous m'indiquer un sous-ensemble
de la norme pouvant garantir la portabilité ?