Éric Lévénez écrit:Tout dépend de ce que l'on appelle "interne" d'unix. Par exemple sur Mac OS
X, qui est un unix, l'interface des fichiers doit utiliser des caractères en
UTF-8 (Unicode 4 sous Panther). L'utilisation d'un nom de fichier avec une
séquence de char 8 bits non conforme UTF-8 retourne une erreur,
contrairement aux autres unix.
Je ne connais pas MacOS, mais ça semble être une fonctionalité du
système de fichiers. Sur un autre système de fichier du même OS (par
exemple, un ISO9960 pour les CD), le jeu de caractère peut être
différent.
L'interface d'affichage dépend, elle, de
l'émulation choisie dans Terminal, qui est par défaut UTF-8.
Éric Lévénez <news@levenez.com> écrit:
Tout dépend de ce que l'on appelle "interne" d'unix. Par exemple sur Mac OS
X, qui est un unix, l'interface des fichiers doit utiliser des caractères en
UTF-8 (Unicode 4 sous Panther). L'utilisation d'un nom de fichier avec une
séquence de char 8 bits non conforme UTF-8 retourne une erreur,
contrairement aux autres unix.
Je ne connais pas MacOS, mais ça semble être une fonctionalité du
système de fichiers. Sur un autre système de fichier du même OS (par
exemple, un ISO9960 pour les CD), le jeu de caractère peut être
différent.
L'interface d'affichage dépend, elle, de
l'émulation choisie dans Terminal, qui est par défaut UTF-8.
Éric Lévénez écrit:Tout dépend de ce que l'on appelle "interne" d'unix. Par exemple sur Mac OS
X, qui est un unix, l'interface des fichiers doit utiliser des caractères en
UTF-8 (Unicode 4 sous Panther). L'utilisation d'un nom de fichier avec une
séquence de char 8 bits non conforme UTF-8 retourne une erreur,
contrairement aux autres unix.
Je ne connais pas MacOS, mais ça semble être une fonctionalité du
système de fichiers. Sur un autre système de fichier du même OS (par
exemple, un ISO9960 pour les CD), le jeu de caractère peut être
différent.
L'interface d'affichage dépend, elle, de
l'émulation choisie dans Terminal, qui est par défaut UTF-8.
La représenation sur un système du char imprimable 'a' sur un
autre système n'est pas nessessairement un caractère imprimable,
ni même un caractère.
La représenation sur un système du char imprimable 'a' sur un
autre système n'est pas nessessairement un caractère imprimable,
ni même un caractère.
La représenation sur un système du char imprimable 'a' sur un
autre système n'est pas nessessairement un caractère imprimable,
ni même un caractère.
Dans l'article <c5h988$hcv$,
Antoine Leca écrit:En 20040413163318$, Vincent Lefevre va escriure:C'est sensé renvoyer un 'a' dans le jeu de caractères des char du
compilateur,
Pas du compilateur, celui de l'hôte.
C'est plus lié au compilateur (en fait à l'ensemble de
l'environnement).
?
Le jeu de caractère de l'environnement, c'est celui de l'hôte.
Le jeu de caractères n'est pas lié à l'hôte, mais au processus
(comme l'ensemble des locales).
Dans le cas d'une compilation,
le processus est le compilateur (enfin, il peut y avoir plusieurs
processus, mais je suppose qu'il n'y aura pas de changement de
jeu de caractères à ce niveau).
Imagine donc un compilateur *nix qui fonctionne avec comme jeu de
caractère interne, Unicode (parfaitement vraissemblable aujourd'hui,
non).
C'est invraissemblable avec des char sur 8 bits (cas de la majorité
des *nix -- enfin je ne connais aucun *nix où ça ne peut être
autrement). Sinon, que signifie
putchar('é');
avec Unicode comme jeu de caractères?
Je parlais de la locale utilisée pour la compilation
et non pas
pour le lancement du programme (bien qu'en pratique, il me semble
qu'il vaille mieux que ce soient des locales compatibles si des
caractères non ASCII sont en dur dans le source).
Dans l'article <c5h988$hcv$1@shakotay.alphanet.ch>,
Antoine Leca <root@localhost.gov> écrit:
En 20040413163318$47d8@vinc17.org, Vincent Lefevre va escriure:
C'est sensé renvoyer un 'a' dans le jeu de caractères des char du
compilateur,
Pas du compilateur, celui de l'hôte.
C'est plus lié au compilateur (en fait à l'ensemble de
l'environnement).
?
Le jeu de caractère de l'environnement, c'est celui de l'hôte.
Le jeu de caractères n'est pas lié à l'hôte, mais au processus
(comme l'ensemble des locales).
Dans le cas d'une compilation,
le processus est le compilateur (enfin, il peut y avoir plusieurs
processus, mais je suppose qu'il n'y aura pas de changement de
jeu de caractères à ce niveau).
Imagine donc un compilateur *nix qui fonctionne avec comme jeu de
caractère interne, Unicode (parfaitement vraissemblable aujourd'hui,
non).
C'est invraissemblable avec des char sur 8 bits (cas de la majorité
des *nix -- enfin je ne connais aucun *nix où ça ne peut être
autrement). Sinon, que signifie
putchar('é');
avec Unicode comme jeu de caractères?
Je parlais de la locale utilisée pour la compilation
et non pas
pour le lancement du programme (bien qu'en pratique, il me semble
qu'il vaille mieux que ce soient des locales compatibles si des
caractères non ASCII sont en dur dans le source).
Dans l'article <c5h988$hcv$,
Antoine Leca écrit:En 20040413163318$, Vincent Lefevre va escriure:C'est sensé renvoyer un 'a' dans le jeu de caractères des char du
compilateur,
Pas du compilateur, celui de l'hôte.
C'est plus lié au compilateur (en fait à l'ensemble de
l'environnement).
?
Le jeu de caractère de l'environnement, c'est celui de l'hôte.
Le jeu de caractères n'est pas lié à l'hôte, mais au processus
(comme l'ensemble des locales).
Dans le cas d'une compilation,
le processus est le compilateur (enfin, il peut y avoir plusieurs
processus, mais je suppose qu'il n'y aura pas de changement de
jeu de caractères à ce niveau).
Imagine donc un compilateur *nix qui fonctionne avec comme jeu de
caractère interne, Unicode (parfaitement vraissemblable aujourd'hui,
non).
C'est invraissemblable avec des char sur 8 bits (cas de la majorité
des *nix -- enfin je ne connais aucun *nix où ça ne peut être
autrement). Sinon, que signifie
putchar('é');
avec Unicode comme jeu de caractères?
Je parlais de la locale utilisée pour la compilation
et non pas
pour le lancement du programme (bien qu'en pratique, il me semble
qu'il vaille mieux que ce soient des locales compatibles si des
caractères non ASCII sont en dur dans le source).
En , Laurent Wacrenier va escriure:La représenation sur un système du char imprimable 'a' sur un
autre système n'est pas nessessairement un caractère imprimable,
Qui a dit que c'était ce qui se passait ?
Depuis quand isprint() est une constante ?ni même un caractère.
Pardon ?
'a' est *toujours* un caractère. Par définition, un caractère est ce qui
rentre dans un multiplet (byte en anglais), et 'a' doit être représentable
(et en plus avoir une valeur positive).
En slrnc7okr1.29i.lwa@victor.teaser.fr, Laurent Wacrenier va escriure:
La représenation sur un système du char imprimable 'a' sur un
autre système n'est pas nessessairement un caractère imprimable,
Qui a dit que c'était ce qui se passait ?
Depuis quand isprint() est une constante ?
ni même un caractère.
Pardon ?
'a' est *toujours* un caractère. Par définition, un caractère est ce qui
rentre dans un multiplet (byte en anglais), et 'a' doit être représentable
(et en plus avoir une valeur positive).
En , Laurent Wacrenier va escriure:La représenation sur un système du char imprimable 'a' sur un
autre système n'est pas nessessairement un caractère imprimable,
Qui a dit que c'était ce qui se passait ?
Depuis quand isprint() est une constante ?ni même un caractère.
Pardon ?
'a' est *toujours* un caractère. Par définition, un caractère est ce qui
rentre dans un multiplet (byte en anglais), et 'a' doit être représentable
(et en plus avoir une valeur positive).
C'est sensé renvoyer un 'a' dans le jeu de caractères des char du
compilateur,
Pas du compilateur, celui de l'hôte.
C'est plus lié au compilateur (en fait à l'ensemble de
l'environnement).
?
Le jeu de caractère de l'environnement, c'est celui de l'hôte.
Le jeu de caractères n'est pas lié à l'hôte, mais au processus
1) Je n'ai jamais écrit écrit que l'hôte était différent d'un processus.
2) En quoi cette « liaison » justifie-t-elle un tant soit peu l'affirmation
que ce n'est pas lié à l'environnement d'exécution (l'hôte), mais bien
plutôt le compilateur ?
(comme l'ensemble des locales).
De quelles locales parle-t-on ? Des locales POSIX ? Que
viennent-elles faire ici ?
Dans le cas d'une compilation, le processus est le compilateur
(enfin, il peut y avoir plusieurs processus, mais je suppose qu'il
n'y aura pas de changement de jeu de caractères à ce niveau).
Mais pourquoi diantre le compilateur devrait être dans un système
comparable à l'environnement d'exécution ? Pourquoi devrait-ce être
un processus ? Est-ce que tu veux obliger le compilateur à être
lui-même un un programme C ?
Imagine donc un compilateur *nix qui fonctionne avec comme jeu de
caractère interne, Unicode (parfaitement vraissemblable aujourd'hui,
non).
C'est invraissemblable avec des char sur 8 bits (cas de la majorité
des *nix -- enfin je ne connais aucun *nix où ça ne peut être
autrement). Sinon, que signifie
putchar('é');
avec Unicode comme jeu de caractères?
Jeu de caractères : ensemble des entités indépendantes.
Tu confonds ici avec la représentation,
Dans la norme C, il y a une distinction très claire entre le jeu de
caractères de base (dont 'a'), qui est obligé d'être encodé dans un
char; et les caractères étendus, dont par exemple 'é', qui pour être
représenté peut nécessiter plusieurs octets (un seul 0xE9 avec
iso-8859-1, mais deux 0xA8,0xA6 en EUC-CN ou 0xC3,0xA9 en utf-8; et
même trois 0x8F,0xAB,0xB1 en EUC-JP)
Je parlais de la locale utilisée pour la compilation
Mais qu'est ce que cela a à voir ?
Reprenons mon exemple d'un compilateur croisé opérant sur une
machine ASCII qui produit du code pour une machine EBCDIC. En quoi
le codage à l'intérieur du compilateur peut-il avoir la moindre
influence sur ce qui est émis dans le binaire ? En fait, si cela
devait avoir la moindre influence, on aurait de grois problèmes, ne
crois-tu pas ?
et non pas pour le lancement du programme (bien qu'en pratique, il
me semble qu'il vaille mieux que ce soient des locales compatibles
si des caractères non ASCII sont en dur dans le source).
Non non. Par exemple, je crois que le compilo C (ou C# ?) de
Microsoft est capable de lire des fichiers UTF-16 (en tous cas,
certains outils de développement le sont). Mais le code produira des
caractères et des chaînes codées avec une "page de codes" à
préciser, sur une base de 8 bits, sauf si tu précises que tu veux
des wchar_t (L'é'), auquel cas tu obtiens de l'UTF-16.
C'est sensé renvoyer un 'a' dans le jeu de caractères des char du
compilateur,
Pas du compilateur, celui de l'hôte.
C'est plus lié au compilateur (en fait à l'ensemble de
l'environnement).
?
Le jeu de caractère de l'environnement, c'est celui de l'hôte.
Le jeu de caractères n'est pas lié à l'hôte, mais au processus
1) Je n'ai jamais écrit écrit que l'hôte était différent d'un processus.
2) En quoi cette « liaison » justifie-t-elle un tant soit peu l'affirmation
que ce n'est pas lié à l'environnement d'exécution (l'hôte), mais bien
plutôt le compilateur ?
(comme l'ensemble des locales).
De quelles locales parle-t-on ? Des locales POSIX ? Que
viennent-elles faire ici ?
Dans le cas d'une compilation, le processus est le compilateur
(enfin, il peut y avoir plusieurs processus, mais je suppose qu'il
n'y aura pas de changement de jeu de caractères à ce niveau).
Mais pourquoi diantre le compilateur devrait être dans un système
comparable à l'environnement d'exécution ? Pourquoi devrait-ce être
un processus ? Est-ce que tu veux obliger le compilateur à être
lui-même un un programme C ?
Imagine donc un compilateur *nix qui fonctionne avec comme jeu de
caractère interne, Unicode (parfaitement vraissemblable aujourd'hui,
non).
C'est invraissemblable avec des char sur 8 bits (cas de la majorité
des *nix -- enfin je ne connais aucun *nix où ça ne peut être
autrement). Sinon, que signifie
putchar('é');
avec Unicode comme jeu de caractères?
Jeu de caractères : ensemble des entités indépendantes.
Tu confonds ici avec la représentation,
Dans la norme C, il y a une distinction très claire entre le jeu de
caractères de base (dont 'a'), qui est obligé d'être encodé dans un
char; et les caractères étendus, dont par exemple 'é', qui pour être
représenté peut nécessiter plusieurs octets (un seul 0xE9 avec
iso-8859-1, mais deux 0xA8,0xA6 en EUC-CN ou 0xC3,0xA9 en utf-8; et
même trois 0x8F,0xAB,0xB1 en EUC-JP)
Je parlais de la locale utilisée pour la compilation
Mais qu'est ce que cela a à voir ?
Reprenons mon exemple d'un compilateur croisé opérant sur une
machine ASCII qui produit du code pour une machine EBCDIC. En quoi
le codage à l'intérieur du compilateur peut-il avoir la moindre
influence sur ce qui est émis dans le binaire ? En fait, si cela
devait avoir la moindre influence, on aurait de grois problèmes, ne
crois-tu pas ?
et non pas pour le lancement du programme (bien qu'en pratique, il
me semble qu'il vaille mieux que ce soient des locales compatibles
si des caractères non ASCII sont en dur dans le source).
Non non. Par exemple, je crois que le compilo C (ou C# ?) de
Microsoft est capable de lire des fichiers UTF-16 (en tous cas,
certains outils de développement le sont). Mais le code produira des
caractères et des chaînes codées avec une "page de codes" à
préciser, sur une base de 8 bits, sauf si tu précises que tu veux
des wchar_t (L'é'), auquel cas tu obtiens de l'UTF-16.
C'est sensé renvoyer un 'a' dans le jeu de caractères des char du
compilateur,
Pas du compilateur, celui de l'hôte.
C'est plus lié au compilateur (en fait à l'ensemble de
l'environnement).
?
Le jeu de caractère de l'environnement, c'est celui de l'hôte.
Le jeu de caractères n'est pas lié à l'hôte, mais au processus
1) Je n'ai jamais écrit écrit que l'hôte était différent d'un processus.
2) En quoi cette « liaison » justifie-t-elle un tant soit peu l'affirmation
que ce n'est pas lié à l'environnement d'exécution (l'hôte), mais bien
plutôt le compilateur ?
(comme l'ensemble des locales).
De quelles locales parle-t-on ? Des locales POSIX ? Que
viennent-elles faire ici ?
Dans le cas d'une compilation, le processus est le compilateur
(enfin, il peut y avoir plusieurs processus, mais je suppose qu'il
n'y aura pas de changement de jeu de caractères à ce niveau).
Mais pourquoi diantre le compilateur devrait être dans un système
comparable à l'environnement d'exécution ? Pourquoi devrait-ce être
un processus ? Est-ce que tu veux obliger le compilateur à être
lui-même un un programme C ?
Imagine donc un compilateur *nix qui fonctionne avec comme jeu de
caractère interne, Unicode (parfaitement vraissemblable aujourd'hui,
non).
C'est invraissemblable avec des char sur 8 bits (cas de la majorité
des *nix -- enfin je ne connais aucun *nix où ça ne peut être
autrement). Sinon, que signifie
putchar('é');
avec Unicode comme jeu de caractères?
Jeu de caractères : ensemble des entités indépendantes.
Tu confonds ici avec la représentation,
Dans la norme C, il y a une distinction très claire entre le jeu de
caractères de base (dont 'a'), qui est obligé d'être encodé dans un
char; et les caractères étendus, dont par exemple 'é', qui pour être
représenté peut nécessiter plusieurs octets (un seul 0xE9 avec
iso-8859-1, mais deux 0xA8,0xA6 en EUC-CN ou 0xC3,0xA9 en utf-8; et
même trois 0x8F,0xAB,0xB1 en EUC-JP)
Je parlais de la locale utilisée pour la compilation
Mais qu'est ce que cela a à voir ?
Reprenons mon exemple d'un compilateur croisé opérant sur une
machine ASCII qui produit du code pour une machine EBCDIC. En quoi
le codage à l'intérieur du compilateur peut-il avoir la moindre
influence sur ce qui est émis dans le binaire ? En fait, si cela
devait avoir la moindre influence, on aurait de grois problèmes, ne
crois-tu pas ?
et non pas pour le lancement du programme (bien qu'en pratique, il
me semble qu'il vaille mieux que ce soient des locales compatibles
si des caractères non ASCII sont en dur dans le source).
Non non. Par exemple, je crois que le compilo C (ou C# ?) de
Microsoft est capable de lire des fichiers UTF-16 (en tous cas,
certains outils de développement le sont). Mais le code produira des
caractères et des chaînes codées avec une "page de codes" à
préciser, sur une base de 8 bits, sauf si tu précises que tu veux
des wchar_t (L'é'), auquel cas tu obtiens de l'UTF-16.
Ce ne sera pas nessessairement un caractère pour le lecteur de la
sortie standard.
Ce ne sera pas nessessairement un caractère pour le lecteur de la
sortie standard.
Ce ne sera pas nessessairement un caractère pour le lecteur de la
sortie standard.
1) Je n'ai jamais écrit écrit que l'hôte était différent d'un
processus.
L'hôte est lié à l'exécution, alors qu'ici on parle de compilation.
2) En quoi cette « liaison » justifie-t-elle un tant soit peu
l'affirmation que ce n'est pas lié à l'environnement d'exécution
(l'hôte), mais bien plutôt le compilateur ?
Parce que quand on compile, les constantes du source comme 'a' ou 'é'
sont stockées en dur dans le code généré.
Si on exécute ce code dans
un environnement ayant un jeu de caractères différent (c'est facile
à changer sous Unix),
on obtiendra un résultat différent (concernant
les caractères, pas les codes eux-mêmes). Les constantes caractère du
source sont bien liées à l'environnement de compilation et non pas à
l'environnement d'exécution.
De quelles locales parle-t-on ? Des locales POSIX ? Que
viennent-elles faire ici ?
Les locales définissant l'environnement du compilateur (dans le
contexte d'une compilation, évidemment).
Imagine donc un compilateur *nix qui fonctionne avec comme jeu de
caractère interne, Unicode (parfaitement vraissemblable
aujourd'hui, non).
C'est invraissemblable avec des char sur 8 bits (cas de la majorité
des *nix -- enfin je ne connais aucun *nix où ça ne peut être
autrement). Sinon, que signifie
putchar('é');
avec Unicode comme jeu de caractères?
Jeu de caractères : ensemble des entités indépendantes.
Tu confonds ici avec la représentation,
Je n'ai pas parlé de représentation, juste du jeu de caractères
(Unicode) et de la taille des char (8 bits dans mon exemple).
Quelle que soit l'encodage (UTF-8, UTF-16...), je ne vois pas
comment ça peut tenir.
Dans la norme C, il y a une distinction très claire entre le jeu de
caractères de base (dont 'a'), qui est obligé d'être encodé dans un
char; et les caractères étendus, dont par exemple 'é', qui pour être
représenté peut nécessiter plusieurs octets (un seul 0xE9 avec
iso-8859-1, mais deux 0xA8,0xA6 en EUC-CN ou 0xC3,0xA9 en utf-8; et
même trois 0x8F,0xAB,0xB1 en EUC-JP)
Quand tu disais "comme jeu de caractère interne, Unicode", j'avais
supposé que tu parlais du jeu de caractères de base. Parce que le
jeu de caractères étendu est peu (ou pas du tout) utilisé sous Unix.
Reprenons mon exemple d'un compilateur croisé opérant sur une
machine ASCII qui produit du code pour une machine EBCDIC. En quoi
le codage à l'intérieur du compilateur peut-il avoir la moindre
influence sur ce qui est émis dans le binaire ? En fait, si cela
devait avoir la moindre influence, on aurait de grois problèmes, ne
crois-tu pas ?
Mauvais exemple, changer d'exemple. Il y a problème quand le jeu de
caractères de l'environnement d'exécution n'est pas fixe.
et non pas pour le lancement du programme (bien qu'en pratique, il
me semble qu'il vaille mieux que ce soient des locales compatibles
si des caractères non ASCII sont en dur dans le source).
Non non. Par exemple, je crois que le compilo C (ou C# ?) de
Microsoft est capable de lire des fichiers UTF-16 (en tous cas,
certains outils de développement le sont). Mais le code produira des
caractères et des chaînes codées avec une "page de codes" à
préciser, sur une base de 8 bits, sauf si tu précises que tu veux
des wchar_t (L'é'), auquel cas tu obtiens de l'UTF-16.
Tu peux le préciser à l'exécution?
1) Je n'ai jamais écrit écrit que l'hôte était différent d'un
processus.
L'hôte est lié à l'exécution, alors qu'ici on parle de compilation.
2) En quoi cette « liaison » justifie-t-elle un tant soit peu
l'affirmation que ce n'est pas lié à l'environnement d'exécution
(l'hôte), mais bien plutôt le compilateur ?
Parce que quand on compile, les constantes du source comme 'a' ou 'é'
sont stockées en dur dans le code généré.
Si on exécute ce code dans
un environnement ayant un jeu de caractères différent (c'est facile
à changer sous Unix),
on obtiendra un résultat différent (concernant
les caractères, pas les codes eux-mêmes). Les constantes caractère du
source sont bien liées à l'environnement de compilation et non pas à
l'environnement d'exécution.
De quelles locales parle-t-on ? Des locales POSIX ? Que
viennent-elles faire ici ?
Les locales définissant l'environnement du compilateur (dans le
contexte d'une compilation, évidemment).
Imagine donc un compilateur *nix qui fonctionne avec comme jeu de
caractère interne, Unicode (parfaitement vraissemblable
aujourd'hui, non).
C'est invraissemblable avec des char sur 8 bits (cas de la majorité
des *nix -- enfin je ne connais aucun *nix où ça ne peut être
autrement). Sinon, que signifie
putchar('é');
avec Unicode comme jeu de caractères?
Jeu de caractères : ensemble des entités indépendantes.
Tu confonds ici avec la représentation,
Je n'ai pas parlé de représentation, juste du jeu de caractères
(Unicode) et de la taille des char (8 bits dans mon exemple).
Quelle que soit l'encodage (UTF-8, UTF-16...), je ne vois pas
comment ça peut tenir.
Dans la norme C, il y a une distinction très claire entre le jeu de
caractères de base (dont 'a'), qui est obligé d'être encodé dans un
char; et les caractères étendus, dont par exemple 'é', qui pour être
représenté peut nécessiter plusieurs octets (un seul 0xE9 avec
iso-8859-1, mais deux 0xA8,0xA6 en EUC-CN ou 0xC3,0xA9 en utf-8; et
même trois 0x8F,0xAB,0xB1 en EUC-JP)
Quand tu disais "comme jeu de caractère interne, Unicode", j'avais
supposé que tu parlais du jeu de caractères de base. Parce que le
jeu de caractères étendu est peu (ou pas du tout) utilisé sous Unix.
Reprenons mon exemple d'un compilateur croisé opérant sur une
machine ASCII qui produit du code pour une machine EBCDIC. En quoi
le codage à l'intérieur du compilateur peut-il avoir la moindre
influence sur ce qui est émis dans le binaire ? En fait, si cela
devait avoir la moindre influence, on aurait de grois problèmes, ne
crois-tu pas ?
Mauvais exemple, changer d'exemple. Il y a problème quand le jeu de
caractères de l'environnement d'exécution n'est pas fixe.
et non pas pour le lancement du programme (bien qu'en pratique, il
me semble qu'il vaille mieux que ce soient des locales compatibles
si des caractères non ASCII sont en dur dans le source).
Non non. Par exemple, je crois que le compilo C (ou C# ?) de
Microsoft est capable de lire des fichiers UTF-16 (en tous cas,
certains outils de développement le sont). Mais le code produira des
caractères et des chaînes codées avec une "page de codes" à
préciser, sur une base de 8 bits, sauf si tu précises que tu veux
des wchar_t (L'é'), auquel cas tu obtiens de l'UTF-16.
Tu peux le préciser à l'exécution?
1) Je n'ai jamais écrit écrit que l'hôte était différent d'un
processus.
L'hôte est lié à l'exécution, alors qu'ici on parle de compilation.
2) En quoi cette « liaison » justifie-t-elle un tant soit peu
l'affirmation que ce n'est pas lié à l'environnement d'exécution
(l'hôte), mais bien plutôt le compilateur ?
Parce que quand on compile, les constantes du source comme 'a' ou 'é'
sont stockées en dur dans le code généré.
Si on exécute ce code dans
un environnement ayant un jeu de caractères différent (c'est facile
à changer sous Unix),
on obtiendra un résultat différent (concernant
les caractères, pas les codes eux-mêmes). Les constantes caractère du
source sont bien liées à l'environnement de compilation et non pas à
l'environnement d'exécution.
De quelles locales parle-t-on ? Des locales POSIX ? Que
viennent-elles faire ici ?
Les locales définissant l'environnement du compilateur (dans le
contexte d'une compilation, évidemment).
Imagine donc un compilateur *nix qui fonctionne avec comme jeu de
caractère interne, Unicode (parfaitement vraissemblable
aujourd'hui, non).
C'est invraissemblable avec des char sur 8 bits (cas de la majorité
des *nix -- enfin je ne connais aucun *nix où ça ne peut être
autrement). Sinon, que signifie
putchar('é');
avec Unicode comme jeu de caractères?
Jeu de caractères : ensemble des entités indépendantes.
Tu confonds ici avec la représentation,
Je n'ai pas parlé de représentation, juste du jeu de caractères
(Unicode) et de la taille des char (8 bits dans mon exemple).
Quelle que soit l'encodage (UTF-8, UTF-16...), je ne vois pas
comment ça peut tenir.
Dans la norme C, il y a une distinction très claire entre le jeu de
caractères de base (dont 'a'), qui est obligé d'être encodé dans un
char; et les caractères étendus, dont par exemple 'é', qui pour être
représenté peut nécessiter plusieurs octets (un seul 0xE9 avec
iso-8859-1, mais deux 0xA8,0xA6 en EUC-CN ou 0xC3,0xA9 en utf-8; et
même trois 0x8F,0xAB,0xB1 en EUC-JP)
Quand tu disais "comme jeu de caractère interne, Unicode", j'avais
supposé que tu parlais du jeu de caractères de base. Parce que le
jeu de caractères étendu est peu (ou pas du tout) utilisé sous Unix.
Reprenons mon exemple d'un compilateur croisé opérant sur une
machine ASCII qui produit du code pour une machine EBCDIC. En quoi
le codage à l'intérieur du compilateur peut-il avoir la moindre
influence sur ce qui est émis dans le binaire ? En fait, si cela
devait avoir la moindre influence, on aurait de grois problèmes, ne
crois-tu pas ?
Mauvais exemple, changer d'exemple. Il y a problème quand le jeu de
caractères de l'environnement d'exécution n'est pas fixe.
et non pas pour le lancement du programme (bien qu'en pratique, il
me semble qu'il vaille mieux que ce soient des locales compatibles
si des caractères non ASCII sont en dur dans le source).
Non non. Par exemple, je crois que le compilo C (ou C# ?) de
Microsoft est capable de lire des fichiers UTF-16 (en tous cas,
certains outils de développement le sont). Mais le code produira des
caractères et des chaînes codées avec une "page de codes" à
préciser, sur une base de 8 bits, sauf si tu précises que tu veux
des wchar_t (L'é'), auquel cas tu obtiens de l'UTF-16.
Tu peux le préciser à l'exécution?
En 20040414125859$, Vincent Lefevre va escriure:1) Je n'ai jamais écrit écrit que l'hôte était différent d'un
processus.
L'hôte est lié à l'exécution, alors qu'ici on parle de compilation.
Mais qui parle de compilation ? Le sujet traite de la norme C90 et de ses
lacunes.
2) En quoi cette « liaison » justifie-t-elle un tant soit peu
l'affirmation que ce n'est pas lié à l'environnement d'exécution
(l'hôte), mais bien plutôt le compilateur ?
Parce que quand on compile, les constantes du source comme 'a' ou 'é'
sont stockées en dur dans le code généré.
Oui. Ces valeurs sont d'ailleurs celles dans le jeu de caractères
d'exécution.
Phase 5 du modèle (5.1.1.2). Le jeu source n'a aucune importance
ici.
Et oui, le compilateur doit connaître le jeu d'exécution.
Si on exécute ce code dans un environnement ayant un jeu de
caractères différent (c'est facile à changer sous Unix),
Non.
D'abord, un 'a' est toujours un 'a'.
Ensuite, si tu changes de locale (ce qui toujours un acte volontaire, il
faut appeler setlocale()) sans tenir compte des encodages, tu invoques un
comportement dépendant de la locale. Si ton programme agit différement dans
ces cas-là, il n'est plus strictement conforme, et encore une fois on est
sorti du propos de cette enfilade.
on obtiendra un résultat différent (concernant les caractères, pas
les codes eux-mêmes). Les constantes caractère du source sont bien
liées à l'environnement de compilation et non pas à
l'environnement d'exécution.
Mais cela n'a rien à voir. On peut parfaitement avoir un compilateur
*nix qui accepte en paramètre la locale d'encodage des caractères.
Ce sera la manière utilisée pour encoder le binaire, autrement dit
le jeu d'exécution.
Sans problèmes: une constante comme 'é' est un entier en C, pas un char.
En fait, le jeu de caractères de base, c'est ASCII sauf $ @ ` (c'est un
point qui a été éclairci en C99).
Mauvais exemple, changer d'exemple. Il y a problème quand le jeu de
caractères de l'environnement d'exécution n'est pas fixe.
EBCDIC est un exemple typique d'enviroennemnt où les jeux de caractères à
l'exécution ne sont *PAS* fixes ;-).
En 20040414125859$15a6@vinc17.org, Vincent Lefevre va escriure:
1) Je n'ai jamais écrit écrit que l'hôte était différent d'un
processus.
L'hôte est lié à l'exécution, alors qu'ici on parle de compilation.
Mais qui parle de compilation ? Le sujet traite de la norme C90 et de ses
lacunes.
2) En quoi cette « liaison » justifie-t-elle un tant soit peu
l'affirmation que ce n'est pas lié à l'environnement d'exécution
(l'hôte), mais bien plutôt le compilateur ?
Parce que quand on compile, les constantes du source comme 'a' ou 'é'
sont stockées en dur dans le code généré.
Oui. Ces valeurs sont d'ailleurs celles dans le jeu de caractères
d'exécution.
Phase 5 du modèle (5.1.1.2). Le jeu source n'a aucune importance
ici.
Et oui, le compilateur doit connaître le jeu d'exécution.
Si on exécute ce code dans un environnement ayant un jeu de
caractères différent (c'est facile à changer sous Unix),
Non.
D'abord, un 'a' est toujours un 'a'.
Ensuite, si tu changes de locale (ce qui toujours un acte volontaire, il
faut appeler setlocale()) sans tenir compte des encodages, tu invoques un
comportement dépendant de la locale. Si ton programme agit différement dans
ces cas-là, il n'est plus strictement conforme, et encore une fois on est
sorti du propos de cette enfilade.
on obtiendra un résultat différent (concernant les caractères, pas
les codes eux-mêmes). Les constantes caractère du source sont bien
liées à l'environnement de compilation et non pas à
l'environnement d'exécution.
Mais cela n'a rien à voir. On peut parfaitement avoir un compilateur
*nix qui accepte en paramètre la locale d'encodage des caractères.
Ce sera la manière utilisée pour encoder le binaire, autrement dit
le jeu d'exécution.
Sans problèmes: une constante comme 'é' est un entier en C, pas un char.
En fait, le jeu de caractères de base, c'est ASCII sauf $ @ ` (c'est un
point qui a été éclairci en C99).
Mauvais exemple, changer d'exemple. Il y a problème quand le jeu de
caractères de l'environnement d'exécution n'est pas fixe.
EBCDIC est un exemple typique d'enviroennemnt où les jeux de caractères à
l'exécution ne sont *PAS* fixes ;-).
En 20040414125859$, Vincent Lefevre va escriure:1) Je n'ai jamais écrit écrit que l'hôte était différent d'un
processus.
L'hôte est lié à l'exécution, alors qu'ici on parle de compilation.
Mais qui parle de compilation ? Le sujet traite de la norme C90 et de ses
lacunes.
2) En quoi cette « liaison » justifie-t-elle un tant soit peu
l'affirmation que ce n'est pas lié à l'environnement d'exécution
(l'hôte), mais bien plutôt le compilateur ?
Parce que quand on compile, les constantes du source comme 'a' ou 'é'
sont stockées en dur dans le code généré.
Oui. Ces valeurs sont d'ailleurs celles dans le jeu de caractères
d'exécution.
Phase 5 du modèle (5.1.1.2). Le jeu source n'a aucune importance
ici.
Et oui, le compilateur doit connaître le jeu d'exécution.
Si on exécute ce code dans un environnement ayant un jeu de
caractères différent (c'est facile à changer sous Unix),
Non.
D'abord, un 'a' est toujours un 'a'.
Ensuite, si tu changes de locale (ce qui toujours un acte volontaire, il
faut appeler setlocale()) sans tenir compte des encodages, tu invoques un
comportement dépendant de la locale. Si ton programme agit différement dans
ces cas-là, il n'est plus strictement conforme, et encore une fois on est
sorti du propos de cette enfilade.
on obtiendra un résultat différent (concernant les caractères, pas
les codes eux-mêmes). Les constantes caractère du source sont bien
liées à l'environnement de compilation et non pas à
l'environnement d'exécution.
Mais cela n'a rien à voir. On peut parfaitement avoir un compilateur
*nix qui accepte en paramètre la locale d'encodage des caractères.
Ce sera la manière utilisée pour encoder le binaire, autrement dit
le jeu d'exécution.
Sans problèmes: une constante comme 'é' est un entier en C, pas un char.
En fait, le jeu de caractères de base, c'est ASCII sauf $ @ ` (c'est un
point qui a été éclairci en C99).
Mauvais exemple, changer d'exemple. Il y a problème quand le jeu de
caractères de l'environnement d'exécution n'est pas fixe.
EBCDIC est un exemple typique d'enviroennemnt où les jeux de caractères à
l'exécution ne sont *PAS* fixes ;-).
Mais qui parle de compilation ? Le sujet traite de la norme C90 et
de ses lacunes.
Le message d'origine de Fabrice (ainsi que les suivants) parle du
résultat de la compilation. Faut suivre!
Parce que quand on compile, les constantes du source comme 'a' ou
'é' sont stockées en dur dans le code généré.
Oui. Ces valeurs sont d'ailleurs celles dans le jeu de caractères
d'exécution.
qui n'est pas forcément défini à l'avance, dans la pratique.
Phase 5 du modèle (5.1.1.2). Le jeu source n'a aucune importance
ici.
Mais je ne parle pas du jeu source, seulement du fait qu'il y a des
constantes de caractère dans le source.
Si on exécute ce code dans un environnement ayant un jeu de
caractères différent (c'est facile à changer sous Unix),
Non.
D'abord, un 'a' est toujours un 'a'.
Ça ne veut rien dire.
Ensuite, si tu changes de locale (ce qui toujours un acte
volontaire, il faut appeler setlocale()) sans tenir compte des
encodages, tu invoques un comportement dépendant de la locale. Si
ton programme agit différement dans ces cas-là, il n'est plus
strictement conforme, et encore une fois on est sorti du propos de
cette enfilade.
Mais c'est bien ce que je disais ici:
<20040410000611$.
on obtiendra un résultat différent (concernant les caractères, pas
les codes eux-mêmes). Les constantes caractère du source sont bien
liées à l'environnement de compilation et non pas à
l'environnement d'exécution.
Mais cela n'a rien à voir. On peut parfaitement avoir un compilateur
*nix qui accepte en paramètre la locale d'encodage des caractères.
Ce sera la manière utilisée pour encoder le binaire, autrement dit
le jeu d'exécution.
Mais ce n'est pas ce qui se passe avec gcc par exemple.
En fait, le jeu de caractères de base, c'est ASCII sauf $ @ ` (c'est
un point qui a été éclairci en C99).
Ça a changé par rapport au draft WG14/N869 alors (je ne le savais
pas); N869 dit seulement "at least".
Mais qui parle de compilation ? Le sujet traite de la norme C90 et
de ses lacunes.
Le message d'origine de Fabrice (ainsi que les suivants) parle du
résultat de la compilation. Faut suivre!
Parce que quand on compile, les constantes du source comme 'a' ou
'é' sont stockées en dur dans le code généré.
Oui. Ces valeurs sont d'ailleurs celles dans le jeu de caractères
d'exécution.
qui n'est pas forcément défini à l'avance, dans la pratique.
Phase 5 du modèle (5.1.1.2). Le jeu source n'a aucune importance
ici.
Mais je ne parle pas du jeu source, seulement du fait qu'il y a des
constantes de caractère dans le source.
Si on exécute ce code dans un environnement ayant un jeu de
caractères différent (c'est facile à changer sous Unix),
Non.
D'abord, un 'a' est toujours un 'a'.
Ça ne veut rien dire.
Ensuite, si tu changes de locale (ce qui toujours un acte
volontaire, il faut appeler setlocale()) sans tenir compte des
encodages, tu invoques un comportement dépendant de la locale. Si
ton programme agit différement dans ces cas-là, il n'est plus
strictement conforme, et encore une fois on est sorti du propos de
cette enfilade.
Mais c'est bien ce que je disais ici:
<20040410000611$490d@vinc17.org>.
on obtiendra un résultat différent (concernant les caractères, pas
les codes eux-mêmes). Les constantes caractère du source sont bien
liées à l'environnement de compilation et non pas à
l'environnement d'exécution.
Mais cela n'a rien à voir. On peut parfaitement avoir un compilateur
*nix qui accepte en paramètre la locale d'encodage des caractères.
Ce sera la manière utilisée pour encoder le binaire, autrement dit
le jeu d'exécution.
Mais ce n'est pas ce qui se passe avec gcc par exemple.
En fait, le jeu de caractères de base, c'est ASCII sauf $ @ ` (c'est
un point qui a été éclairci en C99).
Ça a changé par rapport au draft WG14/N869 alors (je ne le savais
pas); N869 dit seulement "at least".
Mais qui parle de compilation ? Le sujet traite de la norme C90 et
de ses lacunes.
Le message d'origine de Fabrice (ainsi que les suivants) parle du
résultat de la compilation. Faut suivre!
Parce que quand on compile, les constantes du source comme 'a' ou
'é' sont stockées en dur dans le code généré.
Oui. Ces valeurs sont d'ailleurs celles dans le jeu de caractères
d'exécution.
qui n'est pas forcément défini à l'avance, dans la pratique.
Phase 5 du modèle (5.1.1.2). Le jeu source n'a aucune importance
ici.
Mais je ne parle pas du jeu source, seulement du fait qu'il y a des
constantes de caractère dans le source.
Si on exécute ce code dans un environnement ayant un jeu de
caractères différent (c'est facile à changer sous Unix),
Non.
D'abord, un 'a' est toujours un 'a'.
Ça ne veut rien dire.
Ensuite, si tu changes de locale (ce qui toujours un acte
volontaire, il faut appeler setlocale()) sans tenir compte des
encodages, tu invoques un comportement dépendant de la locale. Si
ton programme agit différement dans ces cas-là, il n'est plus
strictement conforme, et encore une fois on est sorti du propos de
cette enfilade.
Mais c'est bien ce que je disais ici:
<20040410000611$.
on obtiendra un résultat différent (concernant les caractères, pas
les codes eux-mêmes). Les constantes caractère du source sont bien
liées à l'environnement de compilation et non pas à
l'environnement d'exécution.
Mais cela n'a rien à voir. On peut parfaitement avoir un compilateur
*nix qui accepte en paramètre la locale d'encodage des caractères.
Ce sera la manière utilisée pour encoder le binaire, autrement dit
le jeu d'exécution.
Mais ce n'est pas ce qui se passe avec gcc par exemple.
En fait, le jeu de caractères de base, c'est ASCII sauf $ @ ` (c'est
un point qui a été éclairci en C99).
Ça a changé par rapport au draft WG14/N869 alors (je ne le savais
pas); N869 dit seulement "at least".
On ne doit pas avoir la même manière de lire...
Je cite:
: 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).
« 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.
Parce que quand on compile, les constantes du source comme 'a' ou
'é' sont stockées en dur dans le code généré.
Oui. Ces valeurs sont d'ailleurs celles dans le jeu de caractères
d'exécution.
qui n'est pas forcément défini à l'avance, dans la pratique.
Je ne sais pas de quelle pratique tu parles.
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.
Si on exécute ce code dans un environnement ayant un jeu de
caractères différent (c'est facile à changer sous Unix),
Non.
D'abord, un 'a' est toujours un 'a'.
Ça ne veut rien dire.
Cela veut dire que avec *nix, tu peux changer autant que tu veux
l'encodage de 'é'. Mais pas celui de 'a'.
Ensuite, si tu changes de locale (ce qui toujours un acte
volontaire, il faut appeler setlocale()) sans tenir compte des
encodages, tu invoques un comportement dépendant de la locale. Si
ton programme agit différement dans ces cas-là, il n'est plus
strictement conforme, et encore une fois on est sorti du propos de
cette enfilade.
Mais c'est bien ce que je disais ici:
<20040410000611$.
Pas tout-à-fait.
Ce que disait, c'était
: > Pour les entrées/sorties on peut fonctionner avec des fichiers textes.
:
: Même avec les fichiers texte. La norme dit:
[couic citation clause 4, paragraphe 5]
: 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).
[Merci alphanet]
Or ici, je fais clairement la distinction entre les caractères du jeu de
base (comme 'a'), qui ne change pas à l'exécution et donc peuvent entrer
dans des programmes strictement conformes, et les caractères comme 'é' qui
ne le peuvent pas. Autrement dit, l'archétype HelloWorld.c est strictement
conforme.
on obtiendra un résultat différent (concernant les caractères, pas
les codes eux-mêmes). Les constantes caractère du source sont bien
liées à l'environnement de compilation et non pas à
l'environnement d'exécution.
Mais cela n'a rien à voir. On peut parfaitement avoir un compilateur
*nix qui accepte en paramètre la locale d'encodage des caractères.
Ce sera la manière utilisée pour encoder le binaire, autrement dit
le jeu d'exécution.
Mais ce n'est pas ce qui se passe avec gcc par exemple.
Non. Et alors ?
En fait, le jeu de caractères de base, c'est ASCII sauf $ @ ` (c'est
un point qui a été éclairci en C99).
Ça a changé par rapport au draft WG14/N869 alors (je ne le savais
pas); N869 dit seulement "at least".
Après vérification, oui.
Bizarre, je me souvenais bien de cette modification, on en avait parlé à
Copenhague (juin 98), mais j'aurais cru que cela avait été écrit plus tôt
que N877 (mars 99) dans le texte de la norme (N869 est daté janvier 99). On
a beaucoup acceléré le développement à ce moment-là, pour ne pas devenir C00
!
Le nouveau (et définitif) texte est:
5.2 Environmental considerations
5.2.1 Character sets
[1] Two sets of characters and their associated collating sequences shall be
defined: the set in which source files are written (the /source character
set/), and the set interpreted in the execution environment (the /execution
character set/). Each set is further divided into a /basic character set/,
whose contents are given by this subclause, and a set of zero or more
locale-specific members (which are not members of the basic character set)
called /extended characters/. The combined set is also called the /extended
character set/. The values of the members of the execution character set are
implementation-defined.
[2] In a character constant or string literal, members of the execution
character set shall be represented by corresponding members of the source
character set or by /escape sequences/ consisting of the backslash
followed by one or more characters. A byte with all bits set to 0, called
the /null character/, shall exist in the basic execution character set; it
is used to terminate a character string.
[3] Both the basic source and basic execution character sets shall have the
following members: [...]
On ne doit pas avoir la même manière de lire...
Je cite:
: 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).
« 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.
Parce que quand on compile, les constantes du source comme 'a' ou
'é' sont stockées en dur dans le code généré.
Oui. Ces valeurs sont d'ailleurs celles dans le jeu de caractères
d'exécution.
qui n'est pas forcément défini à l'avance, dans la pratique.
Je ne sais pas de quelle pratique tu parles.
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.
Si on exécute ce code dans un environnement ayant un jeu de
caractères différent (c'est facile à changer sous Unix),
Non.
D'abord, un 'a' est toujours un 'a'.
Ça ne veut rien dire.
Cela veut dire que avec *nix, tu peux changer autant que tu veux
l'encodage de 'é'. Mais pas celui de 'a'.
Ensuite, si tu changes de locale (ce qui toujours un acte
volontaire, il faut appeler setlocale()) sans tenir compte des
encodages, tu invoques un comportement dépendant de la locale. Si
ton programme agit différement dans ces cas-là, il n'est plus
strictement conforme, et encore une fois on est sorti du propos de
cette enfilade.
Mais c'est bien ce que je disais ici:
<20040410000611$490d@vinc17.org>.
Pas tout-à-fait.
Ce que disait, c'était
: > Pour les entrées/sorties on peut fonctionner avec des fichiers textes.
:
: Même avec les fichiers texte. La norme dit:
[couic citation clause 4, paragraphe 5]
: 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).
[Merci alphanet]
Or ici, je fais clairement la distinction entre les caractères du jeu de
base (comme 'a'), qui ne change pas à l'exécution et donc peuvent entrer
dans des programmes strictement conformes, et les caractères comme 'é' qui
ne le peuvent pas. Autrement dit, l'archétype HelloWorld.c est strictement
conforme.
on obtiendra un résultat différent (concernant les caractères, pas
les codes eux-mêmes). Les constantes caractère du source sont bien
liées à l'environnement de compilation et non pas à
l'environnement d'exécution.
Mais cela n'a rien à voir. On peut parfaitement avoir un compilateur
*nix qui accepte en paramètre la locale d'encodage des caractères.
Ce sera la manière utilisée pour encoder le binaire, autrement dit
le jeu d'exécution.
Mais ce n'est pas ce qui se passe avec gcc par exemple.
Non. Et alors ?
En fait, le jeu de caractères de base, c'est ASCII sauf $ @ ` (c'est
un point qui a été éclairci en C99).
Ça a changé par rapport au draft WG14/N869 alors (je ne le savais
pas); N869 dit seulement "at least".
Après vérification, oui.
Bizarre, je me souvenais bien de cette modification, on en avait parlé à
Copenhague (juin 98), mais j'aurais cru que cela avait été écrit plus tôt
que N877 (mars 99) dans le texte de la norme (N869 est daté janvier 99). On
a beaucoup acceléré le développement à ce moment-là, pour ne pas devenir C00
!
Le nouveau (et définitif) texte est:
5.2 Environmental considerations
5.2.1 Character sets
[1] Two sets of characters and their associated collating sequences shall be
defined: the set in which source files are written (the /source character
set/), and the set interpreted in the execution environment (the /execution
character set/). Each set is further divided into a /basic character set/,
whose contents are given by this subclause, and a set of zero or more
locale-specific members (which are not members of the basic character set)
called /extended characters/. The combined set is also called the /extended
character set/. The values of the members of the execution character set are
implementation-defined.
[2] In a character constant or string literal, members of the execution
character set shall be represented by corresponding members of the source
character set or by /escape sequences/ consisting of the backslash
followed by one or more characters. A byte with all bits set to 0, called
the /null character/, shall exist in the basic execution character set; it
is used to terminate a character string.
[3] Both the basic source and basic execution character sets shall have the
following members: [...]
On ne doit pas avoir la même manière de lire...
Je cite:
: 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).
« 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.
Parce que quand on compile, les constantes du source comme 'a' ou
'é' sont stockées en dur dans le code généré.
Oui. Ces valeurs sont d'ailleurs celles dans le jeu de caractères
d'exécution.
qui n'est pas forcément défini à l'avance, dans la pratique.
Je ne sais pas de quelle pratique tu parles.
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.
Si on exécute ce code dans un environnement ayant un jeu de
caractères différent (c'est facile à changer sous Unix),
Non.
D'abord, un 'a' est toujours un 'a'.
Ça ne veut rien dire.
Cela veut dire que avec *nix, tu peux changer autant que tu veux
l'encodage de 'é'. Mais pas celui de 'a'.
Ensuite, si tu changes de locale (ce qui toujours un acte
volontaire, il faut appeler setlocale()) sans tenir compte des
encodages, tu invoques un comportement dépendant de la locale. Si
ton programme agit différement dans ces cas-là, il n'est plus
strictement conforme, et encore une fois on est sorti du propos de
cette enfilade.
Mais c'est bien ce que je disais ici:
<20040410000611$.
Pas tout-à-fait.
Ce que disait, c'était
: > Pour les entrées/sorties on peut fonctionner avec des fichiers textes.
:
: Même avec les fichiers texte. La norme dit:
[couic citation clause 4, paragraphe 5]
: 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).
[Merci alphanet]
Or ici, je fais clairement la distinction entre les caractères du jeu de
base (comme 'a'), qui ne change pas à l'exécution et donc peuvent entrer
dans des programmes strictement conformes, et les caractères comme 'é' qui
ne le peuvent pas. Autrement dit, l'archétype HelloWorld.c est strictement
conforme.
on obtiendra un résultat différent (concernant les caractères, pas
les codes eux-mêmes). Les constantes caractère du source sont bien
liées à l'environnement de compilation et non pas à
l'environnement d'exécution.
Mais cela n'a rien à voir. On peut parfaitement avoir un compilateur
*nix qui accepte en paramètre la locale d'encodage des caractères.
Ce sera la manière utilisée pour encoder le binaire, autrement dit
le jeu d'exécution.
Mais ce n'est pas ce qui se passe avec gcc par exemple.
Non. Et alors ?
En fait, le jeu de caractères de base, c'est ASCII sauf $ @ ` (c'est
un point qui a été éclairci en C99).
Ça a changé par rapport au draft WG14/N869 alors (je ne le savais
pas); N869 dit seulement "at least".
Après vérification, oui.
Bizarre, je me souvenais bien de cette modification, on en avait parlé à
Copenhague (juin 98), mais j'aurais cru que cela avait été écrit plus tôt
que N877 (mars 99) dans le texte de la norme (N869 est daté janvier 99). On
a beaucoup acceléré le développement à ce moment-là, pour ne pas devenir C00
!
Le nouveau (et définitif) texte est:
5.2 Environmental considerations
5.2.1 Character sets
[1] Two sets of characters and their associated collating sequences shall be
defined: the set in which source files are written (the /source character
set/), and the set interpreted in the execution environment (the /execution
character set/). Each set is further divided into a /basic character set/,
whose contents are given by this subclause, and a set of zero or more
locale-specific members (which are not members of the basic character set)
called /extended characters/. The combined set is also called the /extended
character set/. The values of the members of the execution character set are
implementation-defined.
[2] In a character constant or string literal, members of the execution
character set shall be represented by corresponding members of the source
character set or by /escape sequences/ consisting of the backslash
followed by one or more characters. A byte with all bits set to 0, called
the /null character/, shall exist in the basic execution character set; it
is used to terminate a character string.
[3] Both the basic source and basic execution character sets shall have the
following members: [...]