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...
A moins que sur ces plateformes, tu puisses ouvrir les connexions en mode texte et qu'il te fasse de manière transparente la conversion binaire ASCII -> texte EBCDIC.
Quand bien même, comment saurait-il que le flux entrant est encodé en ASCII ?
Oui, bien sur, en le lui précisant à l'ouverture.
Comment ?
-- 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"
Marc Boyer wrote on 10/11/04 :
cedric wrote:
Marc Boyer wrote:
A moins que sur ces plateformes, tu puisses ouvrir les
connexions en mode texte et qu'il te fasse de manière transparente
la conversion binaire ASCII -> texte EBCDIC.
Quand bien même, comment saurait-il que le flux entrant est encodé en
ASCII ?
Oui, bien sur, en le lui précisant à l'ouverture.
Comment ?
--
Emmanuel
The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html
The C-library: http://www.dinkumware.com/refxc.html
A moins que sur ces plateformes, tu puisses ouvrir les connexions en mode texte et qu'il te fasse de manière transparente la conversion binaire ASCII -> texte EBCDIC.
Quand bien même, comment saurait-il que le flux entrant est encodé en ASCII ?
Oui, bien sur, en le lui précisant à l'ouverture.
Comment ?
-- 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"
Emmanuel Delahaye
Pierre Maurette wrote on 10/11/04 :
Hors, l'ASCII de base est défini
"Or" ! Je vois cette faute de plus en plus souvent, ça m'agace...
-- 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"
Pierre Maurette wrote on 10/11/04 :
Hors, l'ASCII de base est défini
"Or" ! Je vois cette faute de plus en plus souvent, ça m'agace...
--
Emmanuel
The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html
The C-library: http://www.dinkumware.com/refxc.html
On peut supposer que sur mainframe IBM, il existe des fonctions de conversions de chaines ebcdic2ascii() et inversement.
Quel EBCDIC ? Un des grands amusements de ces codages, c'est que les caractères !|@#~`^[]{} (dans l'ordre de mon clavier; notez que ! n'est pas dans la liste des trigraphes) ne sont pas à la même place selon votre place sur le globe, ou plus exactement selon la place de celui qui a créé le fichier.
Antoine
En mn.545f7d4bf5434466.15512@YOURBRAnoos.fr, Emmanuel Delahaye va escriure:
On peut supposer que sur mainframe IBM, il existe des fonctions de
conversions de chaines ebcdic2ascii() et inversement.
Quel EBCDIC ?
Un des grands amusements de ces codages, c'est que les caractères
!|@#~`^[]{} (dans l'ordre de mon clavier; notez que ! n'est pas dans la
liste des trigraphes) ne sont pas à la même place selon votre place sur le
globe, ou plus exactement selon la place de celui qui a créé le fichier.
On peut supposer que sur mainframe IBM, il existe des fonctions de conversions de chaines ebcdic2ascii() et inversement.
Quel EBCDIC ? Un des grands amusements de ces codages, c'est que les caractères !|@#~`^[]{} (dans l'ordre de mon clavier; notez que ! n'est pas dans la liste des trigraphes) ne sont pas à la même place selon votre place sur le globe, ou plus exactement selon la place de celui qui a créé le fichier.
Antoine
cedric
Charlie Gordon wrote:
#include <iso646.h> not_eq
:-)
Oui, quand j'ai découvert ce sommet de la branlette normatoire, je suis tombé de ma chaise ! Pauvres drosophiles :-((
C'est toujours plus lisible qu'un trigraph, non ?
Charlie Gordon wrote:
#include <iso646.h>
not_eq
:-)
Oui, quand j'ai découvert ce sommet de la branlette normatoire, je suis tombé de
ma chaise !
Pauvres drosophiles :-((
Oui, quand j'ai découvert ce sommet de la branlette normatoire, je suis tombé de ma chaise ! Pauvres drosophiles :-((
C'est toujours plus lisible qu'un trigraph, non ?
Pierre Maurette
Emmanuel Delahaye a écrit:
Pierre Maurette wrote on 10/11/04 :
Hors, l'ASCII de base est défini
"Or" ! Je vois cette faute de plus en plus souvent, ça m'agace... Vous m'agacez également.
Qu'elle soit due à l'inattention ou à l'excitation, cette faute ne méritait pas votre agressivité, et je n'accepte pas le ton que prennent souvent vos remarques. Le style n'est pas imposé par la norme, mais il a tout à gagner à rester cohérent. Vous devriez sérieusement vous poser la question de votre goujaterie lunatique. -- Pierre
Emmanuel Delahaye <emdel@YOURBRAnoos.fr> a écrit:
Pierre Maurette wrote on 10/11/04 :
Hors, l'ASCII de base est défini
"Or" ! Je vois cette faute de plus en plus souvent, ça m'agace...
Vous m'agacez également.
Qu'elle soit due à l'inattention ou à l'excitation, cette faute ne
méritait pas votre agressivité, et je n'accepte pas le ton que
prennent souvent vos remarques.
Le style n'est pas imposé par la norme, mais il a tout à gagner à
rester cohérent. Vous devriez sérieusement vous poser la question de
votre goujaterie lunatique.
--
Pierre
"Or" ! Je vois cette faute de plus en plus souvent, ça m'agace... Vous m'agacez également.
Qu'elle soit due à l'inattention ou à l'excitation, cette faute ne méritait pas votre agressivité, et je n'accepte pas le ton que prennent souvent vos remarques. Le style n'est pas imposé par la norme, mais il a tout à gagner à rester cohérent. Vous devriez sérieusement vous poser la question de votre goujaterie lunatique. -- Pierre
Gabriel Dos Reis
Pierre Maurette writes:
| Le style n'est pas imposé par la norme, mais il a tout à gagner à | rester cohérent. Vous devriez sérieusement vous poser la question de | votre goujaterie lunatique.
C'est dans la norme ça ?
-- Gaby
Pierre Maurette <maurettepierre@wanadoo.fr> writes:
| Le style n'est pas imposé par la norme, mais il a tout à gagner à
| rester cohérent. Vous devriez sérieusement vous poser la question de
| votre goujaterie lunatique.
| Le style n'est pas imposé par la norme, mais il a tout à gagner à | rester cohérent. Vous devriez sérieusement vous poser la question de | votre goujaterie lunatique.
C'est dans la norme ça ?
-- Gaby
James Kanze
cedric writes:
|> Jean-Marc wrote: |> > Oui tout à fait. Et contrairement aux idées reçues, un programme C |> > bien écrit tourne sur un mainframe comme sur une autre plateforme. |> > La seule chose, c'est précisément qu'il faut éviter à tout prix |> > les tests du genre:
|> > if(car == 61) /* cherche '=' */ |> > il suffit d'écrire tout à fait normalement |> > if(car == '=') /* cherche '=' */
|> 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...
D'où est-ce que tu lis ces mails ? Parce que la RFC, elle, ne concerne que ce qui se passe entre deux machines, sur la liaison de communication. J'imagine qu'il y a de fortes chances que sur un IBM, le programme qui lit les mails et les stocke sur disque les convertit aussi en EBCDIC. Alors, si tu dois porter ton programme à une telle machine, la première chose à faire serait de se renseigner ce que tu vas recevoir réelement.
À titre d'exemple, la RFC spécifie aussi que les fins de lignes soient représentées par CRLF. Mais dans tous les mails sur mes systèmes (Linux et Solaris), il n'y a qu'un LF.
En gros, si tu as à communiquer avec une autre machine, au moyen de SMTP, il faut que tu t'arranges à convertir le format interne de ton système en ce qu'exige le protocol. Sinon, normalement, tu utilises les formats et les encodages natifs de ton système.
|> Il y a des serveurs smtp sur mainframes ? :-)
Certainement.
-- James Kanze Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
cedric <rixed@happyleptic.NOSPAM.org> writes:
|> Jean-Marc wrote:
|> > Oui tout à fait. Et contrairement aux idées reçues, un programme C
|> > bien écrit tourne sur un mainframe comme sur une autre plateforme.
|> > La seule chose, c'est précisément qu'il faut éviter à tout prix
|> > les tests du genre:
|> > if(car == 61) /* cherche '=' */
|> > il suffit d'écrire tout à fait normalement
|> > if(car == '=') /* cherche '=' */
|> 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...
D'où est-ce que tu lis ces mails ? Parce que la RFC, elle, ne concerne
que ce qui se passe entre deux machines, sur la liaison de
communication. J'imagine qu'il y a de fortes chances que sur un IBM, le
programme qui lit les mails et les stocke sur disque les convertit aussi
en EBCDIC. Alors, si tu dois porter ton programme à une telle machine,
la première chose à faire serait de se renseigner ce que tu vas recevoir
réelement.
À titre d'exemple, la RFC spécifie aussi que les fins de lignes soient
représentées par CRLF. Mais dans tous les mails sur mes systèmes (Linux
et Solaris), il n'y a qu'un LF.
En gros, si tu as à communiquer avec une autre machine, au moyen de
SMTP, il faut que tu t'arranges à convertir le format interne de ton
système en ce qu'exige le protocol. Sinon, normalement, tu utilises les
formats et les encodages natifs de ton système.
|> Il y a des serveurs smtp sur mainframes ? :-)
Certainement.
--
James Kanze
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
|> Jean-Marc wrote: |> > Oui tout à fait. Et contrairement aux idées reçues, un programme C |> > bien écrit tourne sur un mainframe comme sur une autre plateforme. |> > La seule chose, c'est précisément qu'il faut éviter à tout prix |> > les tests du genre:
|> > if(car == 61) /* cherche '=' */ |> > il suffit d'écrire tout à fait normalement |> > if(car == '=') /* cherche '=' */
|> 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...
D'où est-ce que tu lis ces mails ? Parce que la RFC, elle, ne concerne que ce qui se passe entre deux machines, sur la liaison de communication. J'imagine qu'il y a de fortes chances que sur un IBM, le programme qui lit les mails et les stocke sur disque les convertit aussi en EBCDIC. Alors, si tu dois porter ton programme à une telle machine, la première chose à faire serait de se renseigner ce que tu vas recevoir réelement.
À titre d'exemple, la RFC spécifie aussi que les fins de lignes soient représentées par CRLF. Mais dans tous les mails sur mes systèmes (Linux et Solaris), il n'y a qu'un LF.
En gros, si tu as à communiquer avec une autre machine, au moyen de SMTP, il faut que tu t'arranges à convertir le format interne de ton système en ce qu'exige le protocol. Sinon, normalement, tu utilises les formats et les encodages natifs de ton système.
|> Il y a des serveurs smtp sur mainframes ? :-)
Certainement.
-- James Kanze Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
James Kanze
Jean-Marc Bourguet writes:
|> Marc Boyer writes:
[...] |> > Disons que, il me semble qu'il fut un temps ou les gens |> > respectaient le fait que c'était de l'ASCII et où ils faisaient un |> > encodage (les uuencode et base 64 si mes souvenirs sont bons). |> > Non?
|> Pour chaque partie du corps d'un message, il y a un codage de |> transfert qui indique comment il faut transformer ce qui est recu |> pour avoir le vrai contenu (le probleme a resoudre ici est que le |> systeme a ete concu pour transporter des infos sur 7 bits, le 8ieme |> pouvait etre perdu).
C'était le cas. Je crois que ce ne l'est plus. En revanche, le binaire pûr pourrait encore poser des problèmes -- des octets avec des valeurs comme 0x04, par exemple, ont encore une signification spéciale parfois.
-- James Kanze Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
Jean-Marc Bourguet <jm@bourguet.org> writes:
|> Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr.invalid> writes:
[...]
|> > Disons que, il me semble qu'il fut un temps ou les gens
|> > respectaient le fait que c'était de l'ASCII et où ils faisaient un
|> > encodage (les uuencode et base 64 si mes souvenirs sont bons).
|> > Non?
|> Pour chaque partie du corps d'un message, il y a un codage de
|> transfert qui indique comment il faut transformer ce qui est recu
|> pour avoir le vrai contenu (le probleme a resoudre ici est que le
|> systeme a ete concu pour transporter des infos sur 7 bits, le 8ieme
|> pouvait etre perdu).
C'était le cas. Je crois que ce ne l'est plus. En revanche, le binaire
pûr pourrait encore poser des problèmes -- des octets avec des valeurs
comme 0x04, par exemple, ont encore une signification spéciale parfois.
--
James Kanze
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
[...] |> > Disons que, il me semble qu'il fut un temps ou les gens |> > respectaient le fait que c'était de l'ASCII et où ils faisaient un |> > encodage (les uuencode et base 64 si mes souvenirs sont bons). |> > Non?
|> Pour chaque partie du corps d'un message, il y a un codage de |> transfert qui indique comment il faut transformer ce qui est recu |> pour avoir le vrai contenu (le probleme a resoudre ici est que le |> systeme a ete concu pour transporter des infos sur 7 bits, le 8ieme |> pouvait etre perdu).
C'était le cas. Je crois que ce ne l'est plus. En revanche, le binaire pûr pourrait encore poser des problèmes -- des octets avec des valeurs comme 0x04, par exemple, ont encore une signification spéciale parfois.
-- James Kanze Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
