Des nombreuses « plateformes » utilisant 32 bits pour un "byte"
Je n'ai jamais prétendu qu'elles étaient nombreuses.
D'ailleurs je n'en connais aucune.
DSP 56156 Freescale (ex-Motorola) :
#define CHAR_BIT 32
-- A+
Emmanuel Delahaye
Vincent Lefevre
Dans l'article <dop6vm$5fq$, Antoine Leca écrit:
In news:43b01636$0$31140$, loufoque va escriure:
Sur usenet, ou les courriels, le risque de n'importe quoi chez le lecteur
Parce qu'il y a des clients qui sont incapable de lire l'entête indiquant l'encodage des caractères ?
Même s'ils savent le faire, il faut éviter les caractères qui ne sont pas communs à iso-8859-1 et iso-8859-15. Tout le monde n'est pas en iso-8859-15, et utf-8 (qui serait la meilleure solution pour tout harmoniser) n'est pas accepté dans fr.*.
Oh oui !
Pour prendre un exemple dans ce fil, Pierre a ouvert avec Subject: =?ISO-8859-15?Q?Noyeux_Joël_à_tous_...? > Emmanuel a répondu avec Subject: Re: Noyeux =?ISO-8859-15?Q?Joël_à_tous_...? > Vincent, avec Subject: Re: Noyeux Joël à tous ... Jusque là, pas trop de souci. Celui de Vincent est en ligne avec l'ancienne ligne (il faut aller lire d'autre entêtes pour savoir comment décoder le sujet), tandis que Pierre et Emmanuel suivent les régles plus actuelles (utilisation de l'encodage MIME, à la RFC 2047) ;
À noter que l'encodage MIME dans les en-têtes n'est pas correctement interprété par OE, qui introduit des espaces supplémentaires ou les enlève, voire casse plus de choses.
[...]
Mais d'autres ont répondus avec :-( Subject: =?ISO-8859-15?Q?Re:_Noyeux_Joël_à_tous_...? > Et là, un client un peu simplet (qui ne comprend pas le MIME) ne va pas « voir » le Re:, donc il va répondre avec un Subject: Re: =?ISO-8859-15?Q?Re:_Noyeux_Joël_à_tous_...? Je ne suis pas sûr que même un client qui connaisse MIME doive
Dans l'article <dop6vm$5fq$1@shakotay.alphanet.ch>,
Antoine Leca <root@localhost.invalid> écrit:
In news:43b01636$0$31140$636a15ce@news.free.fr, loufoque va escriure:
Sur usenet, ou les courriels, le risque de n'importe quoi chez le
lecteur
Parce qu'il y a des clients qui sont incapable de lire l'entête
indiquant l'encodage des caractères ?
Même s'ils savent le faire, il faut éviter les caractères qui ne sont
pas communs à iso-8859-1 et iso-8859-15. Tout le monde n'est pas en
iso-8859-15, et utf-8 (qui serait la meilleure solution pour tout
harmoniser) n'est pas accepté dans fr.*.
Oh oui !
Pour prendre un exemple dans ce fil, Pierre a ouvert avec
Subject: =?ISO-8859-15?Q?Noyeux_Joël_à_tous_...? > Emmanuel a répondu avec
Subject: Re: Noyeux =?ISO-8859-15?Q?Joël_à_tous_...? > Vincent, avec
Subject: Re: Noyeux Joël à tous ...
Jusque là, pas trop de souci. Celui de Vincent est en ligne avec l'ancienne
ligne (il faut aller lire d'autre entêtes pour savoir comment décoder le
sujet), tandis que Pierre et Emmanuel suivent les régles plus actuelles
(utilisation de l'encodage MIME, à la RFC 2047) ;
À noter que l'encodage MIME dans les en-têtes n'est pas correctement
interprété par OE, qui introduit des espaces supplémentaires ou les
enlève, voire casse plus de choses.
[...]
Mais d'autres ont répondus avec :-(
Subject: =?ISO-8859-15?Q?Re:_Noyeux_Joël_à_tous_...? > Et là, un client un peu simplet (qui ne comprend pas le MIME) ne va pas «
voir » le Re:, donc il va répondre avec un
Subject: Re: =?ISO-8859-15?Q?Re:_Noyeux_Joël_à_tous_...?
Je ne suis pas sûr que même un client qui connaisse MIME doive
Sur usenet, ou les courriels, le risque de n'importe quoi chez le lecteur
Parce qu'il y a des clients qui sont incapable de lire l'entête indiquant l'encodage des caractères ?
Même s'ils savent le faire, il faut éviter les caractères qui ne sont pas communs à iso-8859-1 et iso-8859-15. Tout le monde n'est pas en iso-8859-15, et utf-8 (qui serait la meilleure solution pour tout harmoniser) n'est pas accepté dans fr.*.
Oh oui !
Pour prendre un exemple dans ce fil, Pierre a ouvert avec Subject: =?ISO-8859-15?Q?Noyeux_Joël_à_tous_...? > Emmanuel a répondu avec Subject: Re: Noyeux =?ISO-8859-15?Q?Joël_à_tous_...? > Vincent, avec Subject: Re: Noyeux Joël à tous ... Jusque là, pas trop de souci. Celui de Vincent est en ligne avec l'ancienne ligne (il faut aller lire d'autre entêtes pour savoir comment décoder le sujet), tandis que Pierre et Emmanuel suivent les régles plus actuelles (utilisation de l'encodage MIME, à la RFC 2047) ;
À noter que l'encodage MIME dans les en-têtes n'est pas correctement interprété par OE, qui introduit des espaces supplémentaires ou les enlève, voire casse plus de choses.
[...]
Mais d'autres ont répondus avec :-( Subject: =?ISO-8859-15?Q?Re:_Noyeux_Joël_à_tous_...? > Et là, un client un peu simplet (qui ne comprend pas le MIME) ne va pas « voir » le Re:, donc il va répondre avec un Subject: Re: =?ISO-8859-15?Q?Re:_Noyeux_Joël_à_tous_...? Je ne suis pas sûr que même un client qui connaisse MIME doive
In news:20051226152131$, Vincent Lefevre va escriure:
Mais si par exemple le « é » est traduit en « */ », cela provoquerait une fermeture de commentaire non voulue.
Là par contre, c'est proprement impossible, sauf à utiliser des manipulations de jeux de caractères (genre passer par deux ou trois filtres en pipeline avant d'alimenter le compilateur) spécifiques de la DS9k. Tu transformes un codet (au sens des jeux de caractères, ici e-accent-aigu) en séquence de deux codets (étoile puis barre) qui sont par ailleurs des caractères de base... c'est possible (par exemple avec les jeux de caractères genre ISO-2022-XX) mais pas courant (d'habitude on fait l'inverse), et surtout une telle transformation se fera « dans un état d'encodage différent de l'initial », pour reprendre ce que dit la norme ;
Je pensais plutôt à un source en UTF-8. Le « é » est représenté par une séquence de deux octets, et chacun pourrait être traduit par un caractère du jeu de base, par exemple. On pourrait aussi considérer une implémentation qui va mettre à 0 le 8e bit (comme certains programmes le faisaient dans le passé). D'autre part, si le source est en iso-8859-1 mais que l'implémentation attend un source en utf-8, elle va buter sur la première séquence invalide...
alors si après cette transformation, tu filtres les codets qui indiquent les changements d'état, et que tu passes le résultat au compilo, effectivement l'implémentation va interpréter cela comme une fin de commentaire... mais il y a tellement de source conformes qui vont devenir inutilisables que cela devient une implémentation sans intérêt.
Il doit y avoir relativement peu de sources utilisant des caractères accentués.
C'est en ce sens que j'entendais "sans erreur".
Où est l'erreur ?
L'erreur de l'utilisateur qui va penser que les caractères accentués vont passer sans problème, ou du compilo pas suffisamment documenté.
Dans l'article <dop5c2$1vj$1@shakotay.alphanet.ch>,
Antoine Leca <root@localhost.invalid> écrit:
In news:20051226152131$1736@ay.vinc17.org, Vincent Lefevre va escriure:
Mais si par exemple le « é » est traduit en « */ », cela provoquerait
une fermeture de commentaire non voulue.
Là par contre, c'est proprement impossible, sauf à utiliser des
manipulations de jeux de caractères (genre passer par deux ou trois
filtres en pipeline avant d'alimenter le compilateur) spécifiques de
la DS9k. Tu transformes un codet (au sens des jeux de caractères,
ici e-accent-aigu) en séquence de deux codets (étoile puis barre)
qui sont par ailleurs des caractères de base... c'est possible (par
exemple avec les jeux de caractères genre ISO-2022-XX) mais pas
courant (d'habitude on fait l'inverse), et surtout une telle
transformation se fera « dans un état d'encodage différent de
l'initial », pour reprendre ce que dit la norme ;
Je pensais plutôt à un source en UTF-8. Le « é » est représenté par
une séquence de deux octets, et chacun pourrait être traduit par un
caractère du jeu de base, par exemple. On pourrait aussi considérer
une implémentation qui va mettre à 0 le 8e bit (comme certains
programmes le faisaient dans le passé). D'autre part, si le source
est en iso-8859-1 mais que l'implémentation attend un source en
utf-8, elle va buter sur la première séquence invalide...
alors si après cette transformation, tu filtres les codets qui
indiquent les changements d'état, et que tu passes le résultat au
compilo, effectivement l'implémentation va interpréter cela comme
une fin de commentaire... mais il y a tellement de source conformes
qui vont devenir inutilisables que cela devient une implémentation
sans intérêt.
Il doit y avoir relativement peu de sources utilisant des caractères
accentués.
C'est en ce sens que j'entendais "sans erreur".
Où est l'erreur ?
L'erreur de l'utilisateur qui va penser que les caractères accentués
vont passer sans problème, ou du compilo pas suffisamment documenté.
In news:20051226152131$, Vincent Lefevre va escriure:
Mais si par exemple le « é » est traduit en « */ », cela provoquerait une fermeture de commentaire non voulue.
Là par contre, c'est proprement impossible, sauf à utiliser des manipulations de jeux de caractères (genre passer par deux ou trois filtres en pipeline avant d'alimenter le compilateur) spécifiques de la DS9k. Tu transformes un codet (au sens des jeux de caractères, ici e-accent-aigu) en séquence de deux codets (étoile puis barre) qui sont par ailleurs des caractères de base... c'est possible (par exemple avec les jeux de caractères genre ISO-2022-XX) mais pas courant (d'habitude on fait l'inverse), et surtout une telle transformation se fera « dans un état d'encodage différent de l'initial », pour reprendre ce que dit la norme ;
Je pensais plutôt à un source en UTF-8. Le « é » est représenté par une séquence de deux octets, et chacun pourrait être traduit par un caractère du jeu de base, par exemple. On pourrait aussi considérer une implémentation qui va mettre à 0 le 8e bit (comme certains programmes le faisaient dans le passé). D'autre part, si le source est en iso-8859-1 mais que l'implémentation attend un source en utf-8, elle va buter sur la première séquence invalide...
alors si après cette transformation, tu filtres les codets qui indiquent les changements d'état, et que tu passes le résultat au compilo, effectivement l'implémentation va interpréter cela comme une fin de commentaire... mais il y a tellement de source conformes qui vont devenir inutilisables que cela devient une implémentation sans intérêt.
Il doit y avoir relativement peu de sources utilisant des caractères accentués.
C'est en ce sens que j'entendais "sans erreur".
Où est l'erreur ?
L'erreur de l'utilisateur qui va penser que les caractères accentués vont passer sans problème, ou du compilo pas suffisamment documenté.
In news:43b02417$0$25456$, Emmanuel Delahaye va escriure:
In news:43b0170e$0$31140$, loufoque va escriure:
Des nombreuses « plateformes » utilisant 32 bits pour un "byte"
Je n'ai jamais prétendu qu'elles étaient nombreuses.
D'ailleurs je n'en connais aucune.
Connaître au sens de maîtriser, pas à celui de avoir entendu parler.
DSP 56156 Freescale (ex-Motorola) :
#define CHAR_BIT 32
Et le compilo C utilise UTF-32 ? ;-)
D'ailleurs, est-ce que ton compilo C prétend être conforme à C99, même de loin ?
Antoine
Emmanuel Delahaye
In news:43b02417$0$25456$, Emmanuel Delahaye va escriure:
In news:43b0170e$0$31140$, loufoque va escriure:
Des nombreuses « plateformes » utilisant 32 bits pour un "byte"
Je n'ai jamais prétendu qu'elles étaient nombreuses.
D'ailleurs je n'en connais aucune.
Connaître au sens de maîtriser, pas à celui de avoir entendu parler.
DSP 56156 Freescale (ex-Motorola) :
#define CHAR_BIT 32
Et le compilo C utilise UTF-32 ? ;-)
D'ailleurs, est-ce que ton compilo C prétend être conforme à C99, même de loin ?
Ouh là ! Je crois bien que la dernière version du compilateur C Freescale pour 56156 était bugguée au point qu'il faille ajouter du code en assembleur 'à la main'. Alors faut pas trop lui en demander. Mais il est un fait (et ce n'est pas une question de langage), qu'un byte sur cette machine a une largeur de 32-bit. Point.
De même que sur un Texas TMS320C54, le byte fait 16-bits. C'est inhérent à l'architecture qui est à l'évidence plus orientée calcul que chaine de caractères...
ça surprend la première fois, mais on s'en remet...
-- A+
Emmanuel Delahaye
In news:43b02417$0$25456$79c14f64@nan-newsreader-06.noos.net,
Emmanuel Delahaye va escriure:
In news:43b0170e$0$31140$636a15ce@news.free.fr, loufoque va escriure:
Des nombreuses « plateformes » utilisant 32 bits pour un "byte"
Je n'ai jamais prétendu qu'elles étaient nombreuses.
D'ailleurs je n'en connais aucune.
Connaître au sens de maîtriser, pas à celui de avoir entendu parler.
DSP 56156 Freescale (ex-Motorola) :
#define CHAR_BIT 32
Et le compilo C utilise UTF-32 ? ;-)
D'ailleurs, est-ce que ton compilo C prétend être conforme à C99, même de
loin ?
Ouh là ! Je crois bien que la dernière version du compilateur C
Freescale pour 56156 était bugguée au point qu'il faille ajouter du code
en assembleur 'à la main'. Alors faut pas trop lui en demander. Mais il
est un fait (et ce n'est pas une question de langage), qu'un byte sur
cette machine a une largeur de 32-bit. Point.
De même que sur un Texas TMS320C54, le byte fait 16-bits. C'est inhérent
à l'architecture qui est à l'évidence plus orientée calcul que chaine de
caractères...
In news:43b02417$0$25456$, Emmanuel Delahaye va escriure:
In news:43b0170e$0$31140$, loufoque va escriure:
Des nombreuses « plateformes » utilisant 32 bits pour un "byte"
Je n'ai jamais prétendu qu'elles étaient nombreuses.
D'ailleurs je n'en connais aucune.
Connaître au sens de maîtriser, pas à celui de avoir entendu parler.
DSP 56156 Freescale (ex-Motorola) :
#define CHAR_BIT 32
Et le compilo C utilise UTF-32 ? ;-)
D'ailleurs, est-ce que ton compilo C prétend être conforme à C99, même de loin ?
Ouh là ! Je crois bien que la dernière version du compilateur C Freescale pour 56156 était bugguée au point qu'il faille ajouter du code en assembleur 'à la main'. Alors faut pas trop lui en demander. Mais il est un fait (et ce n'est pas une question de langage), qu'un byte sur cette machine a une largeur de 32-bit. Point.
De même que sur un Texas TMS320C54, le byte fait 16-bits. C'est inhérent à l'architecture qui est à l'évidence plus orientée calcul que chaine de caractères...
ça surprend la première fois, mais on s'en remet...
-- A+
Emmanuel Delahaye
Vincent Lefevre
Dans l'article <43b03d04$0$25695$, Emmanuel Delahaye écrit:
Ouh là ! Je crois bien que la dernière version du compilateur C Freescale pour 56156 était bugguée au point qu'il faille ajouter du code en assembleur 'à la main'. Alors faut pas trop lui en demander. Mais il est un fait (et ce n'est pas une question de langage), qu'un byte sur cette machine a une largeur de 32-bit. Point.
C'est justement une question de langage. On peut très bien mettre 4 caractères dans un mot de 32 bits. C'est ce qui se fait sur Alpha (sauf que c'est du 64 bits, donc il y a 8 caractères), avec un système de masques, non?
Dans l'article <43b03d04$0$25695$79c14f64@nan-newsreader-06.noos.net>,
Emmanuel Delahaye <emdel@yourbranoos.fr> écrit:
Ouh là ! Je crois bien que la dernière version du compilateur C
Freescale pour 56156 était bugguée au point qu'il faille ajouter du code
en assembleur 'à la main'. Alors faut pas trop lui en demander. Mais il
est un fait (et ce n'est pas une question de langage), qu'un byte sur
cette machine a une largeur de 32-bit. Point.
C'est justement une question de langage. On peut très bien mettre
4 caractères dans un mot de 32 bits. C'est ce qui se fait sur Alpha
(sauf que c'est du 64 bits, donc il y a 8 caractères), avec un
système de masques, non?
Dans l'article <43b03d04$0$25695$, Emmanuel Delahaye écrit:
Ouh là ! Je crois bien que la dernière version du compilateur C Freescale pour 56156 était bugguée au point qu'il faille ajouter du code en assembleur 'à la main'. Alors faut pas trop lui en demander. Mais il est un fait (et ce n'est pas une question de langage), qu'un byte sur cette machine a une largeur de 32-bit. Point.
C'est justement une question de langage. On peut très bien mettre 4 caractères dans un mot de 32 bits. C'est ce qui se fait sur Alpha (sauf que c'est du 64 bits, donc il y a 8 caractères), avec un système de masques, non?
? Sur un tas de DSP, et m^me les plus récents, un byte vaut 16 ou 32 bits...
J'avoue avoir remarqué ce phénomène récemment et ça m'a semblé une aberration, étant donné que dans l'esprit d'une personne lambda un byte c'est un octet soit 8 bits.
? Sur un tas de DSP, et m^me les plus récents, un byte vaut 16 ou 32
bits...
J'avoue avoir remarqué ce phénomène récemment et ça m'a semblé une
aberration, étant donné que dans l'esprit d'une personne lambda un byte
c'est un octet soit 8 bits.
? Sur un tas de DSP, et m^me les plus récents, un byte vaut 16 ou 32 bits...
J'avoue avoir remarqué ce phénomène récemment et ça m'a semblé une aberration, étant donné que dans l'esprit d'une personne lambda un byte c'est un octet soit 8 bits.
