Dans l'article <BD10B601.552E%, Eric Lévénez écrit:
Oui, c'est pour cela que j'ai dit "par exemple", pour indiquer que certaines plates-formes pouvaient avoir de l'UTF-8 et un 'é' tenant sur un int. Mais ce n'est pas une certitude, ce n'est donc pas portable, c'est donc illégal (à mon point de vue), même si cela ne l'est pas explicitement dans la norme C.
Ce n'est pas parce que ce n'est pas portable que c'est illégal. On a bien le droit de faire des choses non portables.
-- 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 <BD10B601.552E%news@levenez.com>,
Eric Lévénez <news@levenez.com> écrit:
Oui, c'est pour cela que j'ai dit "par exemple", pour indiquer que
certaines plates-formes pouvaient avoir de l'UTF-8 et un 'é' tenant
sur un int. Mais ce n'est pas une certitude, ce n'est donc pas
portable, c'est donc illégal (à mon point de vue), même si cela ne
l'est pas explicitement dans la norme C.
Ce n'est pas parce que ce n'est pas portable que c'est illégal.
On a bien le droit de faire des choses non portables.
--
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
Dans l'article <BD10B601.552E%, Eric Lévénez écrit:
Oui, c'est pour cela que j'ai dit "par exemple", pour indiquer que certaines plates-formes pouvaient avoir de l'UTF-8 et un 'é' tenant sur un int. Mais ce n'est pas une certitude, ce n'est donc pas portable, c'est donc illégal (à mon point de vue), même si cela ne l'est pas explicitement dans la norme C.
Ce n'est pas parce que ce n'est pas portable que c'est illégal. On a bien le droit de faire des choses non portables.
-- 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
Antoine Leca
En BD1208C7.5647%, Eric Lévénez va escriure:
Où est-il marqué dans la norme que tout type d'encodage des caractères sous la forme 'x' doit obligatoirement tenir sur un int ?
6.4.4.4 ne permet pas de refuser la syntaxe 'abc' (il n'y a pas de contraintes similaire à celle de 6.4.4.4p9 pour les séquences d'échappement).
Mais le résultat est défini par l'implémentation. Par exmple, une implémentation peut parfaitement décider de ne traiter que a et passer complètement outre bc. En UTF-8, cela se traduirait par 'é' == 'è' == 'à' = 0xc3 ou l'équivalent signé.
Mmmm, sauf à utiliser un jeu de caractères différent de Unicode/ISO 10646, ou encore d'anciennes et obsolètes versions, la limite est réellement de 4.
Là tu parles non plus de l'encodage UTF-8 mais de la représentation interne sur 4 octets.
???
Ce que je dis, c'est que le mécanisme UTF-8 (l'encodage), en 2004, ne s'applique qu'à des jeux qui ne dépasse pas 0x10FFFF, ce qui ne nécessite pas plus de 4 octets.
Mais on peut en trouver qui ont un codage UTF-8 sur 5 octets
Un exemple ? Je connais des caractères en 6 octets (U6000000 pour le premier d'entre eux), mais en 5...
La norme UTF-8
Laquelle ?
indique que l'on peut encoder un caractère en 1, 2, 3, 4 ou 5 octets.
Jamais rien vu de tel.
FSS_UTF (l'originale, de Ken Thomson présenté par IBM à X/Open en 1992, P316 chez X/Open), ainsi que les dérivations nommées UTF-8 qui ont vu le jour comme RFC 2044, RFC 2279, amendement 2 à ISO/CÉI 10646-1:1993, UTR#4 de Unicode, etc., jusqu'en 1999 (adoption de la limitation à 0x10ffff), avaient toutes des formes à 6 octets.
Depuis, ISO/CÉI 10646:2003, Unicode 3 et 4, STD63/RFC3629, etc., n'ont plus que des formes à 1-4 octets.
De plus, sauf à utiliser des formes dérogatoires (comme "xF8x80x80x80xAF" pour coder /, histoire de faire sauter un serveur web), les formes à 5 octets, de par les valeurs qu'elles représentent (U00200000 à U03FFFFFF) n'ont jamais représenté aucun caractère, donc formellement sont inutilisables.
Cela n'a rien à voir (enfin presque), avec la représentation interne du caractère en Unicode, par exemple, sur 16 ou 32 bits.
Effectivement, UTF-32 ou UTF-16 (c'est bien cela?) sont des choses (un peu) différentes, auxquelles je ne faisais pas allusion.
(même si en Unicode 4 tout caractère tient sur 4 octets,
Avec 4 octets, tu as un espace d'adressage de 21 bits, plus de 2 millions de caractères. Pour le moment, ils en ont identifié environ 100 000...
Non, là tu confonds la représentation interne Unicode 4 avec l'encodage UTF-8 qui nécessite l'utilisation de bits d'encodage dans chaque octet.
Ne comprend rien.
« Représentation interne » Unicode 4, qu'es aco?
Si tu parles du nom unique de chaque caractère (un entier, normalement écrit comme 4-6 chiffres hexadécimaux avec U+ devant), ce qui est ce dont je parle, il me semble bien qu'il s'agisse d'un « espace d'adressage ». On peut aussi lui donner le nom d'intervalle.
UTF-8 est un encodage, donc une fonction depuis un intervalle vers un ensemble de chaînes (d'octets). Selon les définitions usuelles de UTF-8, l'intervalle de départ est soit [0, 0x7FFFFFF], soit [0, 0x10FFFF]. Dans le premier cas, les chaînes peuvent faire de 1 à 6 octets. Dans le second, de 1 à 4. Les définitions actuelles de UTF-8 impose à cette fonction d'être une bijection (à cause de la faille de sécurité de IIS 4.0, qui a emporté la décision des dubitatifs).
Bien sûr, on peut reprendre le "mécanisme" UTF-8 et l'appliquer à un autre intervalle (par exemple [0,0xFFFFFFFF], en utilisant "xFEx8?abcde") ou un autre répertoire que le « jeu universel », mais tu ne pensais pas à cela, n'est-ce pas?
On aurait le même problème avec d'autres encodages comme l'UTF-32 et une architecture avec des int de 16 bits.
Une implémentation sur une architecture 16 bits où les caractères du source sont codés sur 32 bits, je veux voir...
Là encore tu confonds la représentation interne en Unicode et l'UTF-8. [couic]
Bon, précisons un peu... De quel encodage parle-t-on ?
a) de celui des "Physical source file multibyte characters" (cf. 5.1.1.2p1, 1º)
b) de celui des caractères étendus du jeu source (cf. 5.2.1.2)
c) de la manière qu'a le compilateur de représenter réellement ces derniers (phases 1 à 5 de 5.1.1.2p1)
d) de celui des caractères étendus du jeu d'exécution (cf. 5.2.1.2)
e) de la manière qu'a l'implémentation de représenter réellement ces derniers (phases 6 à 8 de 5.1.1.2p1)
f) ou d'autre chose (non défini par la norme ou plus exactement pour lequel la norme ne définit aucune propriété), qui incluent ceux effectivement utilisés par les données du programme--même si ceux-ci sont souvent les mêmes que ceux du d).
[ Et ne rigolez pas, la norme fait effectivement le tri entre les 5 premières catégories, ce qui rend ce domaine extrêmement confus. ]
Jusqu'à présent, je comprenais la conversation comme traitant du premier. Particulièrement parce que c) et e) n'intéressent réellement que les auteurs du compilateur, que le passage de a) à b) est volontairement flou dans la norme, et que ce que les gens "voient" entre ces deux-là, c'est le premier.
Maintenant, si on parle en fait de d), il sera impossible de faire rentrer des entiers sur 21 bits (UTF-21) dans des int de 16 bits!
Là encore tu confonds la représentation interne en Unicode et l'UTF-8.
Es-tu sûr que je confonde?
De plus il n'est nullement nécessaire d'avoir une représentation interne autre que l'UTF-8,
Si par représentation interne tu te réfères à c) ou e), je suis d'accord.
et donc même l'unicode 4 peut être utilisé sur des architectures 16 bits, en faisant juste attention à ne pas utiliser des choses du type 'é'.
Crac... encore perdu le fil.
Tu parles de compilos écrits en 16 bits ?
Antoine
En BD1208C7.5647%news@levenez.com, Eric Lévénez va escriure:
Où est-il marqué dans la norme que tout type d'encodage des
caractères sous la forme 'x' doit obligatoirement tenir sur un int ?
6.4.4.4 ne permet pas de refuser la syntaxe 'abc' (il n'y a pas de
contraintes similaire à celle de 6.4.4.4p9 pour les séquences
d'échappement).
Mais le résultat est défini par l'implémentation. Par exmple, une
implémentation peut parfaitement décider de ne traiter que a et passer
complètement outre bc. En UTF-8, cela se traduirait par 'é' == 'è' == 'à' = 0xc3 ou l'équivalent signé.
Mmmm, sauf à utiliser un jeu de caractères différent de Unicode/ISO
10646, ou encore d'anciennes et obsolètes versions, la limite est
réellement de 4.
Là tu parles non plus de l'encodage UTF-8 mais de la représentation
interne sur 4 octets.
???
Ce que je dis, c'est que le mécanisme UTF-8 (l'encodage), en 2004, ne
s'applique qu'à des jeux qui ne dépasse pas 0x10FFFF, ce qui ne nécessite
pas plus de 4 octets.
Mais on peut en trouver qui ont un codage UTF-8 sur 5 octets
Un exemple ?
Je connais des caractères en 6 octets (U6000000 pour le premier
d'entre eux), mais en 5...
La norme UTF-8
Laquelle ?
indique que l'on peut encoder un caractère en 1, 2, 3,
4 ou 5 octets.
Jamais rien vu de tel.
FSS_UTF (l'originale, de Ken Thomson présenté par IBM à X/Open en 1992, P316
chez X/Open), ainsi que les dérivations nommées UTF-8 qui ont vu le jour
comme RFC 2044, RFC 2279, amendement 2 à ISO/CÉI 10646-1:1993, UTR#4 de
Unicode, etc., jusqu'en 1999 (adoption de la limitation à 0x10ffff), avaient
toutes des formes à 6 octets.
Depuis, ISO/CÉI 10646:2003, Unicode 3 et 4, STD63/RFC3629, etc., n'ont plus
que des formes à 1-4 octets.
De plus, sauf à utiliser des formes dérogatoires (comme
"xF8x80x80x80xAF" pour coder /, histoire de faire sauter un serveur
web), les formes à 5 octets, de par les valeurs qu'elles représentent
(U00200000 à U03FFFFFF) n'ont jamais représenté aucun caractère, donc
formellement sont inutilisables.
Cela n'a rien à voir (enfin presque), avec la
représentation interne du caractère en Unicode, par exemple, sur 16
ou 32 bits.
Effectivement, UTF-32 ou UTF-16 (c'est bien cela?) sont des choses (un peu)
différentes, auxquelles je ne faisais pas allusion.
(même si en Unicode 4 tout caractère tient sur 4 octets,
Avec 4 octets, tu as un espace d'adressage de 21 bits, plus de 2
millions de caractères. Pour le moment, ils en ont identifié environ
100 000...
Non, là tu confonds la représentation interne Unicode 4 avec
l'encodage UTF-8 qui nécessite l'utilisation de bits
d'encodage dans chaque octet.
Ne comprend rien.
« Représentation interne » Unicode 4, qu'es aco?
Si tu parles du nom unique de chaque caractère (un entier, normalement écrit
comme 4-6 chiffres hexadécimaux avec U+ devant), ce qui est ce dont je
parle, il me semble bien qu'il s'agisse d'un « espace d'adressage ». On peut
aussi lui donner le nom d'intervalle.
UTF-8 est un encodage, donc une fonction depuis un intervalle vers un
ensemble de chaînes (d'octets). Selon les définitions usuelles de UTF-8,
l'intervalle de départ est soit [0, 0x7FFFFFF], soit [0, 0x10FFFF]. Dans le
premier cas, les chaînes peuvent faire de 1 à 6 octets. Dans le second, de 1
à 4. Les définitions actuelles de UTF-8 impose à cette fonction d'être une
bijection (à cause de la faille de sécurité de IIS 4.0, qui a emporté la
décision des dubitatifs).
Bien sûr, on peut reprendre le "mécanisme" UTF-8 et l'appliquer à un autre
intervalle (par exemple [0,0xFFFFFFFF], en utilisant "xFEx8?abcde") ou un
autre répertoire que le « jeu universel », mais tu ne pensais pas à cela,
n'est-ce pas?
On aurait le même problème avec d'autres encodages comme l'UTF-32 et
une architecture avec des int de 16 bits.
Une implémentation sur une architecture 16 bits où les caractères du
source sont codés sur 32 bits, je veux voir...
Là encore tu confonds la représentation interne en Unicode et
l'UTF-8.
[couic]
Bon, précisons un peu... De quel encodage parle-t-on ?
a) de celui des "Physical source file multibyte characters" (cf. 5.1.1.2p1,
1º)
b) de celui des caractères étendus du jeu source (cf. 5.2.1.2)
c) de la manière qu'a le compilateur de représenter réellement ces derniers
(phases 1 à 5 de 5.1.1.2p1)
d) de celui des caractères étendus du jeu d'exécution (cf. 5.2.1.2)
e) de la manière qu'a l'implémentation de représenter réellement ces
derniers (phases 6 à 8 de 5.1.1.2p1)
f) ou d'autre chose (non défini par la norme ou plus exactement pour lequel
la norme ne définit aucune propriété), qui incluent ceux effectivement
utilisés par les données du programme--même si ceux-ci sont souvent les
mêmes que ceux du d).
[ Et ne rigolez pas, la norme fait effectivement le tri entre les 5
premières catégories, ce qui rend ce domaine extrêmement confus. ]
Jusqu'à présent, je comprenais la conversation comme traitant du premier.
Particulièrement parce que c) et e) n'intéressent réellement que les auteurs
du compilateur, que le passage de a) à b) est volontairement flou dans la
norme, et que ce que les gens "voient" entre ces deux-là, c'est le premier.
Maintenant, si on parle en fait de d), il sera impossible de faire rentrer
des entiers sur 21 bits (UTF-21) dans des int de 16 bits!
Là encore tu confonds la représentation interne en Unicode et
l'UTF-8.
Es-tu sûr que je confonde?
De plus il n'est nullement nécessaire d'avoir une
représentation interne autre que l'UTF-8,
Si par représentation interne tu te réfères à c) ou e), je suis d'accord.
et donc même l'unicode 4 peut être utilisé sur des
architectures 16 bits, en faisant juste
attention à ne pas utiliser des choses du type 'é'.
Où est-il marqué dans la norme que tout type d'encodage des caractères sous la forme 'x' doit obligatoirement tenir sur un int ?
6.4.4.4 ne permet pas de refuser la syntaxe 'abc' (il n'y a pas de contraintes similaire à celle de 6.4.4.4p9 pour les séquences d'échappement).
Mais le résultat est défini par l'implémentation. Par exmple, une implémentation peut parfaitement décider de ne traiter que a et passer complètement outre bc. En UTF-8, cela se traduirait par 'é' == 'è' == 'à' = 0xc3 ou l'équivalent signé.
Mmmm, sauf à utiliser un jeu de caractères différent de Unicode/ISO 10646, ou encore d'anciennes et obsolètes versions, la limite est réellement de 4.
Là tu parles non plus de l'encodage UTF-8 mais de la représentation interne sur 4 octets.
???
Ce que je dis, c'est que le mécanisme UTF-8 (l'encodage), en 2004, ne s'applique qu'à des jeux qui ne dépasse pas 0x10FFFF, ce qui ne nécessite pas plus de 4 octets.
Mais on peut en trouver qui ont un codage UTF-8 sur 5 octets
Un exemple ? Je connais des caractères en 6 octets (U6000000 pour le premier d'entre eux), mais en 5...
La norme UTF-8
Laquelle ?
indique que l'on peut encoder un caractère en 1, 2, 3, 4 ou 5 octets.
Jamais rien vu de tel.
FSS_UTF (l'originale, de Ken Thomson présenté par IBM à X/Open en 1992, P316 chez X/Open), ainsi que les dérivations nommées UTF-8 qui ont vu le jour comme RFC 2044, RFC 2279, amendement 2 à ISO/CÉI 10646-1:1993, UTR#4 de Unicode, etc., jusqu'en 1999 (adoption de la limitation à 0x10ffff), avaient toutes des formes à 6 octets.
Depuis, ISO/CÉI 10646:2003, Unicode 3 et 4, STD63/RFC3629, etc., n'ont plus que des formes à 1-4 octets.
De plus, sauf à utiliser des formes dérogatoires (comme "xF8x80x80x80xAF" pour coder /, histoire de faire sauter un serveur web), les formes à 5 octets, de par les valeurs qu'elles représentent (U00200000 à U03FFFFFF) n'ont jamais représenté aucun caractère, donc formellement sont inutilisables.
Cela n'a rien à voir (enfin presque), avec la représentation interne du caractère en Unicode, par exemple, sur 16 ou 32 bits.
Effectivement, UTF-32 ou UTF-16 (c'est bien cela?) sont des choses (un peu) différentes, auxquelles je ne faisais pas allusion.
(même si en Unicode 4 tout caractère tient sur 4 octets,
Avec 4 octets, tu as un espace d'adressage de 21 bits, plus de 2 millions de caractères. Pour le moment, ils en ont identifié environ 100 000...
Non, là tu confonds la représentation interne Unicode 4 avec l'encodage UTF-8 qui nécessite l'utilisation de bits d'encodage dans chaque octet.
Ne comprend rien.
« Représentation interne » Unicode 4, qu'es aco?
Si tu parles du nom unique de chaque caractère (un entier, normalement écrit comme 4-6 chiffres hexadécimaux avec U+ devant), ce qui est ce dont je parle, il me semble bien qu'il s'agisse d'un « espace d'adressage ». On peut aussi lui donner le nom d'intervalle.
UTF-8 est un encodage, donc une fonction depuis un intervalle vers un ensemble de chaînes (d'octets). Selon les définitions usuelles de UTF-8, l'intervalle de départ est soit [0, 0x7FFFFFF], soit [0, 0x10FFFF]. Dans le premier cas, les chaînes peuvent faire de 1 à 6 octets. Dans le second, de 1 à 4. Les définitions actuelles de UTF-8 impose à cette fonction d'être une bijection (à cause de la faille de sécurité de IIS 4.0, qui a emporté la décision des dubitatifs).
Bien sûr, on peut reprendre le "mécanisme" UTF-8 et l'appliquer à un autre intervalle (par exemple [0,0xFFFFFFFF], en utilisant "xFEx8?abcde") ou un autre répertoire que le « jeu universel », mais tu ne pensais pas à cela, n'est-ce pas?
On aurait le même problème avec d'autres encodages comme l'UTF-32 et une architecture avec des int de 16 bits.
Une implémentation sur une architecture 16 bits où les caractères du source sont codés sur 32 bits, je veux voir...
Là encore tu confonds la représentation interne en Unicode et l'UTF-8. [couic]
Bon, précisons un peu... De quel encodage parle-t-on ?
a) de celui des "Physical source file multibyte characters" (cf. 5.1.1.2p1, 1º)
b) de celui des caractères étendus du jeu source (cf. 5.2.1.2)
c) de la manière qu'a le compilateur de représenter réellement ces derniers (phases 1 à 5 de 5.1.1.2p1)
d) de celui des caractères étendus du jeu d'exécution (cf. 5.2.1.2)
e) de la manière qu'a l'implémentation de représenter réellement ces derniers (phases 6 à 8 de 5.1.1.2p1)
f) ou d'autre chose (non défini par la norme ou plus exactement pour lequel la norme ne définit aucune propriété), qui incluent ceux effectivement utilisés par les données du programme--même si ceux-ci sont souvent les mêmes que ceux du d).
[ Et ne rigolez pas, la norme fait effectivement le tri entre les 5 premières catégories, ce qui rend ce domaine extrêmement confus. ]
Jusqu'à présent, je comprenais la conversation comme traitant du premier. Particulièrement parce que c) et e) n'intéressent réellement que les auteurs du compilateur, que le passage de a) à b) est volontairement flou dans la norme, et que ce que les gens "voient" entre ces deux-là, c'est le premier.
Maintenant, si on parle en fait de d), il sera impossible de faire rentrer des entiers sur 21 bits (UTF-21) dans des int de 16 bits!
Là encore tu confonds la représentation interne en Unicode et l'UTF-8.
Es-tu sûr que je confonde?
De plus il n'est nullement nécessaire d'avoir une représentation interne autre que l'UTF-8,
Si par représentation interne tu te réfères à c) ou e), je suis d'accord.
et donc même l'unicode 4 peut être utilisé sur des architectures 16 bits, en faisant juste attention à ne pas utiliser des choses du type 'é'.
Crac... encore perdu le fil.
Tu parles de compilos écrits en 16 bits ?
Antoine
Emmanuel Delahaye
christoleroy a couché sur son écran :
voila, je suis en train de faire un programme en c, qui lance un autre programme par la commande 'SYSTEME("COMMANDE_A_LANCER"); mais le programme stoppe tant que la commande passée n'est pas terminée.
Normal, le C est monotâche.
peut on faire en sorte que lorsque la commande est passée, le programme continue son execution sans attendre que la commande passée soit terminée.
C'est certainement possible si ton système est multitâche. Dans ce cas, il faut appeler la bonne fonction système (fork() ? ... connais pas les détails). Evidemment, se posent ensuite les problèmes de la synchronisation.
Les détails sont à voir sur le forum dédié à ton système.
--
Emmanuel
christoleroy a couché sur son écran :
voila, je suis en train de faire un programme en c, qui lance un autre
programme par la commande 'SYSTEME("COMMANDE_A_LANCER");
mais le programme stoppe tant que la commande passée n'est pas terminée.
Normal, le C est monotâche.
peut on faire en sorte que lorsque la commande est passée,
le programme continue son execution sans attendre que la commande passée soit
terminée.
C'est certainement possible si ton système est multitâche. Dans ce cas,
il faut appeler la bonne fonction système (fork() ? ... connais pas les
détails). Evidemment, se posent ensuite les problèmes de la
synchronisation.
Les détails sont à voir sur le forum dédié à ton système.
voila, je suis en train de faire un programme en c, qui lance un autre programme par la commande 'SYSTEME("COMMANDE_A_LANCER"); mais le programme stoppe tant que la commande passée n'est pas terminée.
Normal, le C est monotâche.
peut on faire en sorte que lorsque la commande est passée, le programme continue son execution sans attendre que la commande passée soit terminée.
C'est certainement possible si ton système est multitâche. Dans ce cas, il faut appeler la bonne fonction système (fork() ? ... connais pas les détails). Evidemment, se posent ensuite les problèmes de la synchronisation.
Les détails sont à voir sur le forum dédié à ton système.
--
Emmanuel
christoleroy
bonjour,
voila, je suis en train de faire un programme en c, qui lance un autre programme par la commande 'SYSTEME("COMMANDE_A_LANCER"); mais le programme stoppe tant que la commande passée n'est pas terminée.
peut on faire en sorte que lorsque la commande est passée,
le programme continue son execution sans attendre que la commande passée soit terminée.
merci et à plus
bonjour,
voila, je suis en train de faire un programme en c, qui lance un autre
programme par la commande 'SYSTEME("COMMANDE_A_LANCER");
mais le programme stoppe tant que la commande passée n'est pas terminée.
peut on faire en sorte que lorsque la commande est passée,
le programme continue son execution sans attendre que la commande passée
soit terminée.
voila, je suis en train de faire un programme en c, qui lance un autre programme par la commande 'SYSTEME("COMMANDE_A_LANCER"); mais le programme stoppe tant que la commande passée n'est pas terminée.
peut on faire en sorte que lorsque la commande est passée,
le programme continue son execution sans attendre que la commande passée soit terminée.
