Une question simple et bête pour changer un peut de la taille des void*:
J'ai un programme qui parse des entêtes de mails, donc, de l'ASCII.
Par exemple, je cherche le caractère ascii du signe égual dans un
buffer. Or, rien ne me dit que je peu chercher le caractère C '=' car a
priori l'encodage local n'est pas nécessairement de l'ASCII. Le
programme cherche donc la valeur numérique de ce caractère (61).
Je me demande si toutes ces précautions ne sont pas exagérées, d'autant
qu'elles alourdissent le programme (surtout lorsqu'il faut chercher des
chaînes de caractères, case insensitive, l'horreur!).
Bref, connaissez vous beaucoup d'architectures encore vivantes qui
utilisent un autre encodage que l'ASCII et sur lesquelles tournent des
serveurs de mails ? Sinon, je remplace tout ça par des belles strings C
et je pourrai utiliser strcmp et consorts...
Sinon, si un serveur smtp codé en C et compilé avec un compilateur pour qui l'encodage local est l'ebcdic, recoit un 61 sur un socket ( > en ascii), je ne voit pas trop comment il va deviner que ca correspond au '=' du compilateur...
Bah, il suffit que le système (qui manipule les sockets comme bon lui semble, il doit y avoir une raison pour laquelle un noyau Unix avec socket est deux fois plus gros que le même sans socket) passe 126. Et le tour est joué.
Antoine
En 4191da6a$0$7417$636a15ce@news.free.fr, cedric va escriure:
Sinon, si un serveur smtp codé en C et compilé avec un compilateur
pour qui l'encodage local est l'ebcdic, recoit un 61 sur un socket ( > en ascii), je ne voit pas trop comment il va deviner que ca
correspond au '=' du compilateur...
Bah, il suffit que le système (qui manipule les sockets comme bon lui
semble, il doit y avoir une raison pour laquelle un noyau Unix avec socket
est deux fois plus gros que le même sans socket) passe 126.
Et le tour est joué.
Sinon, si un serveur smtp codé en C et compilé avec un compilateur pour qui l'encodage local est l'ebcdic, recoit un 61 sur un socket ( > en ascii), je ne voit pas trop comment il va deviner que ca correspond au '=' du compilateur...
Bah, il suffit que le système (qui manipule les sockets comme bon lui semble, il doit y avoir une raison pour laquelle un noyau Unix avec socket est deux fois plus gros que le même sans socket) passe 126. Et le tour est joué.
Antoine
Pierre Maurette
"Antoine Leca" a écrit:
En , Pierre Maurette va escriure:
#if '=' == 61
Marche pas. Dans la logique C, le préprocesseur est une chose, et le compilateur (et donc la machine cible) en est une autre. Et il se trouve qu'historiquement (et pour des raisons évidentes de simplicité), les préprocesseurs croisés font les opérations (évaluer les #if) dans leurs propres environnements, pas dans un environnement (simulé) de la cible. Idem pour les calculs en flottants au niveau du compilateur lui-même. Tout ceci est permis par la norme.
Donc si tu utilises un compilo croisé vers la machine EBCDIC, mais opérant sur une bécane Unix, tu va avoir '=' == 61 alors même que la cible est « caca ». M'étonne qu'à moitié. Pour avoir parcouru la norme sur les jeux de
caractères et le 8 étapes de la "traduction" :-( D'ailleurs, pour les flottants, en y réfléchissant, c'est assez logique. Le principe "wait and see" reste valable. Je ne suis pas au fait des chaînes "normales" de production, mais en cas de cross compilation, on doit pouvoir imaginer une "debug" avec un test dans l'exe, ou un assert(). On peut préparer le terrain en regroupant des constantes caractères et chaînes et pouvoir ainsi "utiliser strcmp et consorts...". Il me semble que cedric s'interroge sur la pertinence d'une perte de productivité en regard de la probabilité d'une non portabilité. Autant je comprends son questionnement dans le cas présent, autant ça me fait parfois sourire. Ici, le raisonnement est sain: la cible, ce sont les plateformes susceptibles d'accueillir un serveur de courrier électronique. -- Pierre
"Antoine Leca" <root@localhost.gov> a écrit:
En v2e3p0ld22i2t4c94t0q6ov6j42j62n3al@4ax.com, Pierre Maurette va escriure:
#if '=' == 61
Marche pas.
Dans la logique C, le préprocesseur est une chose, et le compilateur (et
donc la machine cible) en est une autre.
Et il se trouve qu'historiquement (et pour des raisons évidentes de
simplicité), les préprocesseurs croisés font les opérations (évaluer les
#if) dans leurs propres environnements, pas dans un environnement (simulé)
de la cible.
Idem pour les calculs en flottants au niveau du compilateur lui-même.
Tout ceci est permis par la norme.
Donc si tu utilises un compilo croisé vers la machine EBCDIC, mais opérant
sur une bécane Unix, tu va avoir '=' == 61 alors même que la cible est «
caca ».
M'étonne qu'à moitié. Pour avoir parcouru la norme sur les jeux de
caractères et le 8 étapes de la "traduction" :-(
D'ailleurs, pour les flottants, en y réfléchissant, c'est assez
logique.
Le principe "wait and see" reste valable. Je ne suis pas au fait des
chaînes "normales" de production, mais en cas de cross compilation, on
doit pouvoir imaginer une "debug" avec un test dans l'exe, ou un
assert(). On peut préparer le terrain en regroupant des constantes
caractères et chaînes et pouvoir ainsi "utiliser strcmp et
consorts...".
Il me semble que cedric s'interroge sur la pertinence d'une perte de
productivité en regard de la probabilité d'une non portabilité. Autant
je comprends son questionnement dans le cas présent, autant ça me fait
parfois sourire. Ici, le raisonnement est sain: la cible, ce sont les
plateformes susceptibles d'accueillir un serveur de courrier
électronique.
--
Pierre
Marche pas. Dans la logique C, le préprocesseur est une chose, et le compilateur (et donc la machine cible) en est une autre. Et il se trouve qu'historiquement (et pour des raisons évidentes de simplicité), les préprocesseurs croisés font les opérations (évaluer les #if) dans leurs propres environnements, pas dans un environnement (simulé) de la cible. Idem pour les calculs en flottants au niveau du compilateur lui-même. Tout ceci est permis par la norme.
Donc si tu utilises un compilo croisé vers la machine EBCDIC, mais opérant sur une bécane Unix, tu va avoir '=' == 61 alors même que la cible est « caca ». M'étonne qu'à moitié. Pour avoir parcouru la norme sur les jeux de
caractères et le 8 étapes de la "traduction" :-( D'ailleurs, pour les flottants, en y réfléchissant, c'est assez logique. Le principe "wait and see" reste valable. Je ne suis pas au fait des chaînes "normales" de production, mais en cas de cross compilation, on doit pouvoir imaginer une "debug" avec un test dans l'exe, ou un assert(). On peut préparer le terrain en regroupant des constantes caractères et chaînes et pouvoir ainsi "utiliser strcmp et consorts...". Il me semble que cedric s'interroge sur la pertinence d'une perte de productivité en regard de la probabilité d'une non portabilité. Autant je comprends son questionnement dans le cas présent, autant ça me fait parfois sourire. Ici, le raisonnement est sain: la cible, ce sont les plateformes susceptibles d'accueillir un serveur de courrier électronique. -- Pierre
Antoine Leca
En , Pierre Maurette va escriure:
"Antoine Leca" a écrit:
#if '=' == 61
Marche pas.
Le principe "wait and see" reste valable.
Certes. Mais il faut l'écrire
if( '=' <> 61 ) appelle_le_dragon();
Un compilo normal (sur une cible ASCII) va repérer l'expression constante et au pire va te sortir un avertissement intelligent disant que « du code n'est jamais exécuté ». Bien sûr, le compilateur de Vincent va lui attendre la phase d'exécution, au cas où.
Antoine
En 2404p0l82p93u3peoqjpj762hlhl1n4dlt@4ax.com, Pierre Maurette va escriure:
"Antoine Leca" <root@localhost.gov> a écrit:
#if '=' == 61
Marche pas.
Le principe "wait and see" reste valable.
Certes. Mais il faut l'écrire
if( '=' <> 61 )
appelle_le_dragon();
Un compilo normal (sur une cible ASCII) va repérer l'expression constante et
au pire va te sortir un avertissement intelligent disant que « du code n'est
jamais exécuté ». Bien sûr, le compilateur de Vincent va lui attendre la
phase d'exécution, au cas où.
Un compilo normal (sur une cible ASCII) va repérer l'expression constante et au pire va te sortir un avertissement intelligent disant que « du code n'est jamais exécuté ». Bien sûr, le compilateur de Vincent va lui attendre la phase d'exécution, au cas où.
Antoine
Jean-Marc Bourguet
"Antoine Leca" writes:
if( '=' <> 61 )
Tu fais du Pascal pour le moment?
appelle_le_dragon();
A+
-- Jean-Marc FAQ de fclc: http://www.isty-info.uvsq.fr/~rumeau/fclc Site de usenet-fr: http://www.usenet-fr.news.eu.org
"Antoine Leca" <root@localhost.gov> writes:
if( '=' <> 61 )
Tu fais du Pascal pour le moment?
appelle_le_dragon();
A+
--
Jean-Marc
FAQ de fclc: http://www.isty-info.uvsq.fr/~rumeau/fclc
Site de usenet-fr: http://www.usenet-fr.news.eu.org
-- Jean-Marc FAQ de fclc: http://www.isty-info.uvsq.fr/~rumeau/fclc Site de usenet-fr: http://www.usenet-fr.news.eu.org
Pierre Maurette
"Antoine Leca" a écrit:
En , Pierre Maurette va escriure:
"Antoine Leca" a écrit:
#if '=' == 61
Marche pas.
Le principe "wait and see" reste valable.
Certes. Mais il faut l'écrire
if( '=' <> 61 ) appelle_le_dragon();
Un compilo normal (sur une cible ASCII) va repérer l'expression constante et au pire va te sortir un avertissement intelligent disant que « du code n'est jamais exécuté ». volatile const char groui = 61;
if( '=' != groui ) appelle_le_dragon();
(Le C, c'est casse-biroute. Voilà, c'est dit !)
Bien sûr, le compilateur de Vincent va lui attendre la phase d'exécution, au cas où. C'est kwa, le compilateur de Vincent ?
-- Pierre
"Antoine Leca" <root@localhost.gov> a écrit:
En 2404p0l82p93u3peoqjpj762hlhl1n4dlt@4ax.com, Pierre Maurette va escriure:
"Antoine Leca" <root@localhost.gov> a écrit:
#if '=' == 61
Marche pas.
Le principe "wait and see" reste valable.
Certes. Mais il faut l'écrire
if( '=' <> 61 )
appelle_le_dragon();
Un compilo normal (sur une cible ASCII) va repérer l'expression constante et
au pire va te sortir un avertissement intelligent disant que « du code n'est
jamais exécuté ».
volatile const char groui = 61;
if( '=' != groui )
appelle_le_dragon();
(Le C, c'est casse-biroute. Voilà, c'est dit !)
Bien sûr, le compilateur de Vincent va lui attendre la
phase d'exécution, au cas où.
C'est kwa, le compilateur de Vincent ?
Un compilo normal (sur une cible ASCII) va repérer l'expression constante et au pire va te sortir un avertissement intelligent disant que « du code n'est jamais exécuté ». volatile const char groui = 61;
if( '=' != groui ) appelle_le_dragon();
(Le C, c'est casse-biroute. Voilà, c'est dit !)
Bien sûr, le compilateur de Vincent va lui attendre la phase d'exécution, au cas où. C'est kwa, le compilateur de Vincent ?
-- Pierre
Antoine Leca
En , Jean-Marc Bourguet va escriure:
"Antoine Leca" writes:
if( '=' <> 61 ) Tu fais du Pascal pour le moment?
Mouais. Y avait trop de signe =, cela ne me plaisait pas. Et avec le gag de changer de clavier deux fois par jour, je craque. 8-/
Antoine
En pxbwtwtlq9u.fsf@news.bourguet.org, Jean-Marc Bourguet va escriure:
"Antoine Leca" <root@localhost.gov> writes:
if( '=' <> 61 )
Tu fais du Pascal pour le moment?
Mouais.
Y avait trop de signe =, cela ne me plaisait pas. Et avec le gag de changer
de clavier deux fois par jour, je craque. 8-/
Bon, c'était quoi, le sujet du fil, à propos. Ah oui, codage local ASCII...
Emmanuel Delahaye
cedric wrote on 10/11/04 :
Heu... Oui sauf que là je parlais de parser des mails. Or, les RFC sont précis : le contenu des headers des mails est encodé en ASCII, et tant pis pour les mainframes. Donc, on ne cherche pas '=' mais bien 61... D'où mes soucis...
On peut supposer que sur mainframe IBM, il existe des fonctions de conversions de chaines ebcdic2ascii() et inversement.
Il y a des serveurs smtp sur mainframes ? :-)
Aucune idée.
Ils doivent alors utiliser un fonction de conversion de string du genre to_ascii(char *) ??
Probablement.
(à ce propos, je découvre qu'il existe une fonction C (BSD) qui s'appelle : int toascii(int car);
et qui ... fait un and binaire avec 127 ! arf arf, rien à voir avec une conversion ascii...
C'est assez rustique en effet. Disons que ça limite la valeur à l'ensemble ASCII, soit 0-127.
-- Emmanuel The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html The C-library: http://www.dinkumware.com/refxc.html
"C is a sharp tool"
cedric wrote on 10/11/04 :
Heu... Oui sauf que là je parlais de parser des mails.
Or, les RFC sont précis : le contenu des headers des mails est encodé en
ASCII, et tant pis pour les mainframes. Donc, on ne cherche pas '=' mais bien
61... D'où mes soucis...
On peut supposer que sur mainframe IBM, il existe des fonctions de
conversions de chaines ebcdic2ascii() et inversement.
Il y a des serveurs smtp sur mainframes ? :-)
Aucune idée.
Ils doivent alors utiliser un fonction de conversion de string du
genre to_ascii(char *) ??
Probablement.
(à ce propos, je découvre qu'il existe une fonction C (BSD) qui s'appelle :
int toascii(int car);
et qui ... fait un and binaire avec 127 ! arf arf, rien à voir avec une
conversion ascii...
C'est assez rustique en effet. Disons que ça limite la valeur à
l'ensemble ASCII, soit 0-127.
--
Emmanuel
The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html
The C-library: http://www.dinkumware.com/refxc.html
Heu... Oui sauf que là je parlais de parser des mails. Or, les RFC sont précis : le contenu des headers des mails est encodé en ASCII, et tant pis pour les mainframes. Donc, on ne cherche pas '=' mais bien 61... D'où mes soucis...
On peut supposer que sur mainframe IBM, il existe des fonctions de conversions de chaines ebcdic2ascii() et inversement.
Il y a des serveurs smtp sur mainframes ? :-)
Aucune idée.
Ils doivent alors utiliser un fonction de conversion de string du genre to_ascii(char *) ??
Probablement.
(à ce propos, je découvre qu'il existe une fonction C (BSD) qui s'appelle : int toascii(int car);
et qui ... fait un and binaire avec 127 ! arf arf, rien à voir avec une conversion ascii...
C'est assez rustique en effet. Disons que ça limite la valeur à l'ensemble ASCII, soit 0-127.
-- Emmanuel The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html The C-library: http://www.dinkumware.com/refxc.html
