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...
|> Je répète moi aussi : il ne s'agit pas d'écrire (printf) mais de |> lire un flux codé sur une machine dont l'encodage est différent.
Si tu implémentes un serveur SMTP, qui communique effectivement directement avec les autres machines, il faut que tu t'arranges à transcoder tout ce qui entre et qui sort. De toute façon, et de façon générale -- il faudrait, par exemple, que tu envoies des CRLF à la place des simples 'n', par exemple.
Pour toute la reste, je partirai du principe que les données sont en code interne habituelle de la machine. Et si je communiquais avec d'autres machines, la conversion entre la représentation interne et la représentation externe se ferait au plus bas niveau -- dans une implémentation de SMTP, par exemple, dans les fonctions qui lit et qui écrit les lignes sur l'interface. De façon à ce que dans mon programme, je ne verrai jamais que la représentation native.
-- 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:
|> Je répète moi aussi : il ne s'agit pas d'écrire (printf) mais de
|> lire un flux codé sur une machine dont l'encodage est différent.
Si tu implémentes un serveur SMTP, qui communique effectivement
directement avec les autres machines, il faut que tu t'arranges à
transcoder tout ce qui entre et qui sort. De toute façon, et de façon
générale -- il faudrait, par exemple, que tu envoies des CRLF à la place
des simples 'n', par exemple.
Pour toute la reste, je partirai du principe que les données sont en
code interne habituelle de la machine. Et si je communiquais avec
d'autres machines, la conversion entre la représentation interne et la
représentation externe se ferait au plus bas niveau -- dans une
implémentation de SMTP, par exemple, dans les fonctions qui lit et qui
écrit les lignes sur l'interface. De façon à ce que dans mon programme,
je ne verrai jamais que la représentation native.
--
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
|> Je répète moi aussi : il ne s'agit pas d'écrire (printf) mais de |> lire un flux codé sur une machine dont l'encodage est différent.
Si tu implémentes un serveur SMTP, qui communique effectivement directement avec les autres machines, il faut que tu t'arranges à transcoder tout ce qui entre et qui sort. De toute façon, et de façon générale -- il faudrait, par exemple, que tu envoies des CRLF à la place des simples 'n', par exemple.
Pour toute la reste, je partirai du principe que les données sont en code interne habituelle de la machine. Et si je communiquais avec d'autres machines, la conversion entre la représentation interne et la représentation externe se ferait au plus bas niveau -- dans une implémentation de SMTP, par exemple, dans les fonctions qui lit et qui écrit les lignes sur l'interface. De façon à ce que dans mon programme, je ne verrai jamais que la représentation native.
-- 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
cedric writes:
|> Oui, mais je doute que sur un mainframe, par exemple, et ceci dit |> sans vouloir énerver personne, ladite fonction parvienne à convertir |> par ce moyen un caractère local en ascii ;) Disons que je trouve le |> nom de la fonction un peu trompeur.
Le nom n'est pas assez parlant. Dans ce cas-ci, toascii ne veut pas dire convertirToAscii, mais forceToAscii.
-- 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:
|> Oui, mais je doute que sur un mainframe, par exemple, et ceci dit
|> sans vouloir énerver personne, ladite fonction parvienne à convertir
|> par ce moyen un caractère local en ascii ;) Disons que je trouve le
|> nom de la fonction un peu trompeur.
Le nom n'est pas assez parlant. Dans ce cas-ci, toascii ne veut pas dire
convertirToAscii, mais forceToAscii.
--
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
|> Oui, mais je doute que sur un mainframe, par exemple, et ceci dit |> sans vouloir énerver personne, ladite fonction parvienne à convertir |> par ce moyen un caractère local en ascii ;) Disons que je trouve le |> nom de la fonction un peu trompeur.
Le nom n'est pas assez parlant. Dans ce cas-ci, toascii ne veut pas dire convertirToAscii, mais forceToAscii.
-- 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
Emmanuel Delahaye writes:
|> > 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.
En fait, ça date d'une époque où la mémoire était sévérement limitée, et les machines très lentes. Alors, les autres « fonctions » (qui était en fait des macros) de ctype ne fonctionnait que sur des caractères de -1 (EOF) à 127, pour que la table dont elles se servaient soit plus petite. Et si c'est vrai que quelque chose du genre « (c & 0x80 != 0) ? 0 : c » aurait été plus robuste, il avait le désavantage d'évaluer son paramètre deux fois, dans le cas où c'était un macro.
On fait ce qu'on peut, avec les moyens qu'on a, et tant pis pour l'avenir.
-- 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
Emmanuel Delahaye <emdel@YOURBRAnoos.fr> writes:
|> > 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.
En fait, ça date d'une époque où la mémoire était sévérement limitée, et
les machines très lentes. Alors, les autres « fonctions » (qui était en
fait des macros) de ctype ne fonctionnait que sur des caractères de -1
(EOF) à 127, pour que la table dont elles se servaient soit plus petite.
Et si c'est vrai que quelque chose du genre « (c & 0x80 != 0) ? 0 : c »
aurait été plus robuste, il avait le désavantage d'évaluer son paramètre
deux fois, dans le cas où c'était un macro.
On fait ce qu'on peut, avec les moyens qu'on a, et tant pis pour
l'avenir.
--
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
|> > 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.
En fait, ça date d'une époque où la mémoire était sévérement limitée, et les machines très lentes. Alors, les autres « fonctions » (qui était en fait des macros) de ctype ne fonctionnait que sur des caractères de -1 (EOF) à 127, pour que la table dont elles se servaient soit plus petite. Et si c'est vrai que quelque chose du genre « (c & 0x80 != 0) ? 0 : c » aurait été plus robuste, il avait le désavantage d'évaluer son paramètre deux fois, dans le cas où c'était un macro.
On fait ce qu'on peut, avec les moyens qu'on a, et tant pis pour l'avenir.
-- 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
Antoine Leca
En , James Kanze va escriure: [ toascii() ]
et qui ... fait un and binaire avec 127 ! arf arf, rien à voir avec une conversion ascii...
En fait, ça date d'une époque où la mémoire était sévérement limitée, et les machines très lentes.
... et les lignes téléphoniques très mauvaises, donc tout le traffic était encodé sur 7 bits plus un bit de parité. Sur une bécane qui recevait le traffic dans un octet, le bit de parité se retrouvait automatiquement dans le poids fort. toascii() le faisait disparaître.
Antoine
En m27joso0xt.fsf@lns-vlq-28-82-254-73-206.adsl.proxad.net,
James Kanze va escriure:
[ toascii() ]
et qui ... fait un and binaire avec 127 ! arf arf, rien à voir
avec une conversion ascii...
En fait, ça date d'une époque où la mémoire était sévérement limitée,
et les machines très lentes.
... et les lignes téléphoniques très mauvaises, donc tout le traffic était
encodé sur 7 bits plus un bit de parité. Sur une bécane qui recevait le
traffic dans un octet, le bit de parité se retrouvait automatiquement dans
le poids fort. toascii() le faisait disparaître.
et qui ... fait un and binaire avec 127 ! arf arf, rien à voir avec une conversion ascii...
En fait, ça date d'une époque où la mémoire était sévérement limitée, et les machines très lentes.
... et les lignes téléphoniques très mauvaises, donc tout le traffic était encodé sur 7 bits plus un bit de parité. Sur une bécane qui recevait le traffic dans un octet, le bit de parité se retrouvait automatiquement dans le poids fort. toascii() le faisait disparaître.
Antoine
Pierre Maurette
James Kanze a écrit:
cedric writes:
|> Oui, mais je doute que sur un mainframe, par exemple, et ceci dit |> sans vouloir énerver personne, ladite fonction parvienne à convertir |> par ce moyen un caractère local en ascii ;) Disons que je trouve le |> nom de la fonction un peu trompeur.
Le nom n'est pas assez parlant. Dans ce cas-ci, toascii ne veut pas dire convertirToAscii, mais forceToAscii. Attention, ToAscii est une fonction (clavier) de winuser.h ;-)
J'ai regardé toascii() sur Google. Certaines définitions n'utilisent même pas le mot "ascii", et quand il y est, il n'explique rien de plus: c'est un masquage "& 0x7F". Le proto est: int toascii(int); Remarquez, les fonctions normalisées de ctype.h qui elles sont utiles ont le même proto. -- Pierre
James Kanze <james.kanze@free.fr> a écrit:
cedric <rixed@happyleptic.NOSPAM.org> writes:
|> Oui, mais je doute que sur un mainframe, par exemple, et ceci dit
|> sans vouloir énerver personne, ladite fonction parvienne à convertir
|> par ce moyen un caractère local en ascii ;) Disons que je trouve le
|> nom de la fonction un peu trompeur.
Le nom n'est pas assez parlant. Dans ce cas-ci, toascii ne veut pas dire
convertirToAscii, mais forceToAscii.
Attention, ToAscii est une fonction (clavier) de winuser.h ;-)
J'ai regardé toascii() sur Google. Certaines définitions n'utilisent
même pas le mot "ascii", et quand il y est, il n'explique rien de
plus: c'est un masquage "& 0x7F". Le proto est:
int toascii(int);
Remarquez, les fonctions normalisées de ctype.h qui elles sont utiles
ont le même proto.
--
Pierre
|> Oui, mais je doute que sur un mainframe, par exemple, et ceci dit |> sans vouloir énerver personne, ladite fonction parvienne à convertir |> par ce moyen un caractère local en ascii ;) Disons que je trouve le |> nom de la fonction un peu trompeur.
Le nom n'est pas assez parlant. Dans ce cas-ci, toascii ne veut pas dire convertirToAscii, mais forceToAscii. Attention, ToAscii est une fonction (clavier) de winuser.h ;-)
J'ai regardé toascii() sur Google. Certaines définitions n'utilisent même pas le mot "ascii", et quand il y est, il n'explique rien de plus: c'est un masquage "& 0x7F". Le proto est: int toascii(int); Remarquez, les fonctions normalisées de ctype.h qui elles sont utiles ont le même proto. -- Pierre
James Kanze
"Antoine Leca" writes:
|> En , |> James Kanze va escriure: |> [ toascii() ] |> >>> > et qui ... fait un and binaire avec 127 ! arf arf, rien à voir |> >>> > avec une conversion ascii...
|> > En fait, ça date d'une époque où la mémoire était sévérement |> > limitée, et les machines très lentes.
|> ... et les lignes téléphoniques très mauvaises, donc tout le traffic |> était encodé sur 7 bits plus un bit de parité. Sur une bécane qui |> recevait le traffic dans un octet, le bit de parité se retrouvait |> automatiquement dans le poids fort. toascii() le faisait |> disparaître.
Sauf que sur les machines où j'ai réelement vu tosacii, le masquage du bit de parité se faisait dans les couches basses du pilote du contrôleur séries, et les programmes utilisateurs ne le voyaient jamais. Et que s'ils le voyaient, c'est ou bien que le SIO était mal programmé (et qu'ils devaient en tenir compte aussi dans des choses comme strcmp, ce qui n'était pas le cas), ou bien, plus souvent, que l'utilisateur avait rédirigé les entrées depuis un fichier binaire (et que la meilleure chose à faire aurait été de détecter que les entrées étaient foirées, et s'en aller proprement avec un message d'erreur).
-- 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
"Antoine Leca" <root@localhost.gov> writes:
|> En m27joso0xt.fsf@lns-vlq-28-82-254-73-206.adsl.proxad.net,
|> James Kanze va escriure:
|> [ toascii() ]
|> >>> > et qui ... fait un and binaire avec 127 ! arf arf, rien à voir
|> >>> > avec une conversion ascii...
|> > En fait, ça date d'une époque où la mémoire était sévérement
|> > limitée, et les machines très lentes.
|> ... et les lignes téléphoniques très mauvaises, donc tout le traffic
|> était encodé sur 7 bits plus un bit de parité. Sur une bécane qui
|> recevait le traffic dans un octet, le bit de parité se retrouvait
|> automatiquement dans le poids fort. toascii() le faisait
|> disparaître.
Sauf que sur les machines où j'ai réelement vu tosacii, le masquage du
bit de parité se faisait dans les couches basses du pilote du contrôleur
séries, et les programmes utilisateurs ne le voyaient jamais. Et que
s'ils le voyaient, c'est ou bien que le SIO était mal programmé (et
qu'ils devaient en tenir compte aussi dans des choses comme strcmp, ce
qui n'était pas le cas), ou bien, plus souvent, que l'utilisateur avait
rédirigé les entrées depuis un fichier binaire (et que la meilleure
chose à faire aurait été de détecter que les entrées étaient foirées, et
s'en aller proprement avec un message d'erreur).
--
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
|> En , |> James Kanze va escriure: |> [ toascii() ] |> >>> > et qui ... fait un and binaire avec 127 ! arf arf, rien à voir |> >>> > avec une conversion ascii...
|> > En fait, ça date d'une époque où la mémoire était sévérement |> > limitée, et les machines très lentes.
|> ... et les lignes téléphoniques très mauvaises, donc tout le traffic |> était encodé sur 7 bits plus un bit de parité. Sur une bécane qui |> recevait le traffic dans un octet, le bit de parité se retrouvait |> automatiquement dans le poids fort. toascii() le faisait |> disparaître.
Sauf que sur les machines où j'ai réelement vu tosacii, le masquage du bit de parité se faisait dans les couches basses du pilote du contrôleur séries, et les programmes utilisateurs ne le voyaient jamais. Et que s'ils le voyaient, c'est ou bien que le SIO était mal programmé (et qu'ils devaient en tenir compte aussi dans des choses comme strcmp, ce qui n'était pas le cas), ou bien, plus souvent, que l'utilisateur avait rédirigé les entrées depuis un fichier binaire (et que la meilleure chose à faire aurait été de détecter que les entrées étaient foirées, et s'en aller proprement avec un message d'erreur).
-- 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
James Kanze writes:
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.
Plus precisement les extensions qui permettent d'etre sur que le transport du 8ieme bit sont bien repandues au point que j'ai ete surpris l'autre jour de recevoir un message sans accents mais avec -- entre autres signes qu'il y avait bien eu une perte du 8ieme bit -- un i a la place d'un e accent aigu.
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
James Kanze <james.kanze@free.fr> writes:
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.
Plus precisement les extensions qui permettent d'etre sur que le
transport du 8ieme bit sont bien repandues au point que j'ai ete
surpris l'autre jour de recevoir un message sans accents mais avec --
entre autres signes qu'il y avait bien eu une perte du 8ieme bit -- un
i a la place d'un e accent aigu.
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
[...] |> > 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.
Plus precisement les extensions qui permettent d'etre sur que le transport du 8ieme bit sont bien repandues au point que j'ai ete surpris l'autre jour de recevoir un message sans accents mais avec -- entre autres signes qu'il y avait bien eu une perte du 8ieme bit -- un i a la place d'un e accent aigu.
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
Charlie Gordon
"Pierre Maurette" wrote in message news:
James Kanze a écrit:
cedric writes:
|> Oui, mais je doute que sur un mainframe, par exemple, et ceci dit |> sans vouloir énerver personne, ladite fonction parvienne à convertir |> par ce moyen un caractère local en ascii ;) Disons que je trouve le |> nom de la fonction un peu trompeur.
Le nom n'est pas assez parlant. Dans ce cas-ci, toascii ne veut pas dire convertirToAscii, mais forceToAscii. Attention, ToAscii est une fonction (clavier) de winuser.h ;-)
J'ai regardé toascii() sur Google. Certaines définitions n'utilisent même pas le mot "ascii", et quand il y est, il n'explique rien de plus: c'est un masquage "& 0x7F". Le proto est: int toascii(int); Remarquez, les fonctions normalisées de ctype.h qui elles sont utiles ont le même proto.
toascii() servait à masquer le bit de parité, après lecture sur un port série par exemple ou la parité n'était pas gérée par le hardware. plus très utile de nos jours ;-)
Chqrlie.
"Pierre Maurette" <maurettepierre@wanadoo.fr> wrote in message
news:ipj7p0p45vmpf34f7ep4kf0haste1vmlv1@4ax.com...
James Kanze <james.kanze@free.fr> a écrit:
cedric <rixed@happyleptic.NOSPAM.org> writes:
|> Oui, mais je doute que sur un mainframe, par exemple, et ceci dit
|> sans vouloir énerver personne, ladite fonction parvienne à convertir
|> par ce moyen un caractère local en ascii ;) Disons que je trouve le
|> nom de la fonction un peu trompeur.
Le nom n'est pas assez parlant. Dans ce cas-ci, toascii ne veut pas dire
convertirToAscii, mais forceToAscii.
Attention, ToAscii est une fonction (clavier) de winuser.h ;-)
J'ai regardé toascii() sur Google. Certaines définitions n'utilisent
même pas le mot "ascii", et quand il y est, il n'explique rien de
plus: c'est un masquage "& 0x7F". Le proto est:
int toascii(int);
Remarquez, les fonctions normalisées de ctype.h qui elles sont utiles
ont le même proto.
toascii() servait à masquer le bit de parité, après lecture sur un port série
par exemple ou la parité n'était pas gérée par le hardware.
plus très utile de nos jours ;-)
|> Oui, mais je doute que sur un mainframe, par exemple, et ceci dit |> sans vouloir énerver personne, ladite fonction parvienne à convertir |> par ce moyen un caractère local en ascii ;) Disons que je trouve le |> nom de la fonction un peu trompeur.
Le nom n'est pas assez parlant. Dans ce cas-ci, toascii ne veut pas dire convertirToAscii, mais forceToAscii. Attention, ToAscii est une fonction (clavier) de winuser.h ;-)
J'ai regardé toascii() sur Google. Certaines définitions n'utilisent même pas le mot "ascii", et quand il y est, il n'explique rien de plus: c'est un masquage "& 0x7F". Le proto est: int toascii(int); Remarquez, les fonctions normalisées de ctype.h qui elles sont utiles ont le même proto.
toascii() servait à masquer le bit de parité, après lecture sur un port série par exemple ou la parité n'était pas gérée par le hardware. plus très utile de nos jours ;-)
Chqrlie.
Charlie Gordon
"James Kanze" wrote in message news:
"Antoine Leca" writes:
|> En , |> James Kanze va escriure: |> [ toascii() ] |> >>> > et qui ... fait un and binaire avec 127 ! arf arf, rien à voir |> >>> > avec une conversion ascii...
|> > En fait, ça date d'une époque où la mémoire était sévérement |> > limitée, et les machines très lentes.
|> ... et les lignes téléphoniques très mauvaises, donc tout le traffic |> était encodé sur 7 bits plus un bit de parité. Sur une bécane qui |> recevait le traffic dans un octet, le bit de parité se retrouvait |> automatiquement dans le poids fort. toascii() le faisait |> disparaître.
Sauf que sur les machines où j'ai réelement vu tosacii, le masquage du bit de parité se faisait dans les couches basses du pilote du contrôleur séries, et les programmes utilisateurs ne le voyaient jamais. Et que s'ils le voyaient, c'est ou bien que le SIO était mal programmé (et qu'ils devaient en tenir compte aussi dans des choses comme strcmp, ce qui n'était pas le cas), ou bien, plus souvent, que l'utilisateur avait rédirigé les entrées depuis un fichier binaire (et que la meilleure chose à faire aurait été de détecter que les entrées étaient foirées, et s'en aller proprement avec un message d'erreur).
C était le langage d'implémentation d'unix et de ses drivers, où l'utilisation de macros comme toascii() était loisible, même si la plupart de la libc (stdio) était inutilisable dans ce contexte
D'autre part, à l'époque, j'ai utilisé beaucoup de machines où le port série était géré directement dans les programmes. On avait pas nécessairement 48 couches d'abstraction, ni la place de les faire tenir dans les contraintes physiques d'alors. C'était certainement pas très propre, mais ça faisait de la programmation un métier de spécialistes.
Aujourd'hui, c'est devenu si facile de se vautrer dans des implémentations gargantuesques et inefficaces que cette profession est polluée par des légions de pisseurs de code sans cervelle que leur hiérarchie incompétente n'a aucun moyen de détecter, mais qu'elle facture sans vergogne à des clients qui pensent encore naïvement que la taille de leurs sous-traitants est un gage d'excellence.
J'espère n'avoir choqué personne sur ce forum, de nos jours un programmeur qui s'intéresse au C et nous lit a peu de chances de faire partie de la population qui m'irrite, donc il est clair que je ne vise personne en particulier. Mais ça soulage.
Chqrlie.
"James Kanze" <james.kanze@free.fr> wrote in message
news:m2is8c6l99.fsf@thomas.gabi-soft.fr...
"Antoine Leca" <root@localhost.gov> writes:
|> En m27joso0xt.fsf@lns-vlq-28-82-254-73-206.adsl.proxad.net,
|> James Kanze va escriure:
|> [ toascii() ]
|> >>> > et qui ... fait un and binaire avec 127 ! arf arf, rien à voir
|> >>> > avec une conversion ascii...
|> > En fait, ça date d'une époque où la mémoire était sévérement
|> > limitée, et les machines très lentes.
|> ... et les lignes téléphoniques très mauvaises, donc tout le traffic
|> était encodé sur 7 bits plus un bit de parité. Sur une bécane qui
|> recevait le traffic dans un octet, le bit de parité se retrouvait
|> automatiquement dans le poids fort. toascii() le faisait
|> disparaître.
Sauf que sur les machines où j'ai réelement vu tosacii, le masquage du
bit de parité se faisait dans les couches basses du pilote du contrôleur
séries, et les programmes utilisateurs ne le voyaient jamais. Et que
s'ils le voyaient, c'est ou bien que le SIO était mal programmé (et
qu'ils devaient en tenir compte aussi dans des choses comme strcmp, ce
qui n'était pas le cas), ou bien, plus souvent, que l'utilisateur avait
rédirigé les entrées depuis un fichier binaire (et que la meilleure
chose à faire aurait été de détecter que les entrées étaient foirées, et
s'en aller proprement avec un message d'erreur).
C était le langage d'implémentation d'unix et de ses drivers, où l'utilisation
de macros comme toascii() était loisible, même si la plupart de la libc (stdio)
était inutilisable dans ce contexte
D'autre part, à l'époque, j'ai utilisé beaucoup de machines où le port série
était géré directement dans les programmes. On avait pas nécessairement 48
couches d'abstraction, ni la place de les faire tenir dans les contraintes
physiques d'alors.
C'était certainement pas très propre, mais ça faisait de la programmation un
métier de spécialistes.
Aujourd'hui, c'est devenu si facile de se vautrer dans des implémentations
gargantuesques et inefficaces que cette profession est polluée par des légions
de pisseurs de code sans cervelle que leur hiérarchie incompétente n'a aucun
moyen de détecter, mais qu'elle facture sans vergogne à des clients qui pensent
encore naïvement que la taille de leurs sous-traitants est un gage d'excellence.
J'espère n'avoir choqué personne sur ce forum, de nos jours un programmeur qui
s'intéresse au C et nous lit a peu de chances de faire partie de la population
qui m'irrite, donc il est clair que je ne vise personne en particulier. Mais ça
soulage.
|> En , |> James Kanze va escriure: |> [ toascii() ] |> >>> > et qui ... fait un and binaire avec 127 ! arf arf, rien à voir |> >>> > avec une conversion ascii...
|> > En fait, ça date d'une époque où la mémoire était sévérement |> > limitée, et les machines très lentes.
|> ... et les lignes téléphoniques très mauvaises, donc tout le traffic |> était encodé sur 7 bits plus un bit de parité. Sur une bécane qui |> recevait le traffic dans un octet, le bit de parité se retrouvait |> automatiquement dans le poids fort. toascii() le faisait |> disparaître.
Sauf que sur les machines où j'ai réelement vu tosacii, le masquage du bit de parité se faisait dans les couches basses du pilote du contrôleur séries, et les programmes utilisateurs ne le voyaient jamais. Et que s'ils le voyaient, c'est ou bien que le SIO était mal programmé (et qu'ils devaient en tenir compte aussi dans des choses comme strcmp, ce qui n'était pas le cas), ou bien, plus souvent, que l'utilisateur avait rédirigé les entrées depuis un fichier binaire (et que la meilleure chose à faire aurait été de détecter que les entrées étaient foirées, et s'en aller proprement avec un message d'erreur).
C était le langage d'implémentation d'unix et de ses drivers, où l'utilisation de macros comme toascii() était loisible, même si la plupart de la libc (stdio) était inutilisable dans ce contexte
D'autre part, à l'époque, j'ai utilisé beaucoup de machines où le port série était géré directement dans les programmes. On avait pas nécessairement 48 couches d'abstraction, ni la place de les faire tenir dans les contraintes physiques d'alors. C'était certainement pas très propre, mais ça faisait de la programmation un métier de spécialistes.
Aujourd'hui, c'est devenu si facile de se vautrer dans des implémentations gargantuesques et inefficaces que cette profession est polluée par des légions de pisseurs de code sans cervelle que leur hiérarchie incompétente n'a aucun moyen de détecter, mais qu'elle facture sans vergogne à des clients qui pensent encore naïvement que la taille de leurs sous-traitants est un gage d'excellence.
J'espère n'avoir choqué personne sur ce forum, de nos jours un programmeur qui s'intéresse au C et nous lit a peu de chances de faire partie de la population qui m'irrite, donc il est clair que je ne vise personne en particulier. Mais ça soulage.
Chqrlie.
James Kanze
"Charlie Gordon" writes:
|> "Pierre Maurette" wrote in message |> news: |> > James Kanze a écrit:
|> > >cedric writes:
|> > >|> Oui, mais je doute que sur un mainframe, par exemple, et ceci |> > >|> dit sans vouloir énerver personne, ladite fonction parvienne |> > >|> à convertir par ce moyen un caractère local en ascii ;) |> > >|> Disons que je trouve le nom de la fonction un peu trompeur.
|> > >Le nom n'est pas assez parlant. Dans ce cas-ci, toascii ne veut |> > >pas dire convertirToAscii, mais forceToAscii.
|> > Attention, ToAscii est une fonction (clavier) de winuser.h ;-) |> > J'ai regardé toascii() sur Google. Certaines définitions |> > n'utilisent même pas le mot "ascii", et quand il y est, il |> > n'explique rien de plus: c'est un masquage "& 0x7F". Le proto est: |> > int toascii(int);
|> > Remarquez, les fonctions normalisées de ctype.h qui elles sont |> > utiles ont le même proto.
|> toascii() servait à masquer le bit de parité, après lecture sur un |> port série par exemple ou la parité n'était pas gérée par le |> hardware. plus très utile de nos jours ;-)
Alors, qu'est-ce qu'il a, ou avait, à faire dans ctype.h ? Et pourquoi un nom aussi trompeur de toascii ? Ce genre de fonctionnement (encore utile dans certains cas particuliers) appartient au niveau système, mais dans ce cas-là, si je ne le fais pas directement en ligne dans le code, je l'appelle quelque chose du genre removeParityBit().
-- 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
"Charlie Gordon" <news@chqrlie.org> writes:
|> "Pierre Maurette" <maurettepierre@wanadoo.fr> wrote in message
|> news:ipj7p0p45vmpf34f7ep4kf0haste1vmlv1@4ax.com...
|> > James Kanze <james.kanze@free.fr> a écrit:
|> > >|> Oui, mais je doute que sur un mainframe, par exemple, et ceci
|> > >|> dit sans vouloir énerver personne, ladite fonction parvienne
|> > >|> à convertir par ce moyen un caractère local en ascii ;)
|> > >|> Disons que je trouve le nom de la fonction un peu trompeur.
|> > >Le nom n'est pas assez parlant. Dans ce cas-ci, toascii ne veut
|> > >pas dire convertirToAscii, mais forceToAscii.
|> > Attention, ToAscii est une fonction (clavier) de winuser.h ;-)
|> > J'ai regardé toascii() sur Google. Certaines définitions
|> > n'utilisent même pas le mot "ascii", et quand il y est, il
|> > n'explique rien de plus: c'est un masquage "& 0x7F". Le proto est:
|> > int toascii(int);
|> > Remarquez, les fonctions normalisées de ctype.h qui elles sont
|> > utiles ont le même proto.
|> toascii() servait à masquer le bit de parité, après lecture sur un
|> port série par exemple ou la parité n'était pas gérée par le
|> hardware. plus très utile de nos jours ;-)
Alors, qu'est-ce qu'il a, ou avait, à faire dans ctype.h ? Et pourquoi
un nom aussi trompeur de toascii ? Ce genre de fonctionnement (encore
utile dans certains cas particuliers) appartient au niveau système, mais
dans ce cas-là, si je ne le fais pas directement en ligne dans le code,
je l'appelle quelque chose du genre removeParityBit().
--
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
|> "Pierre Maurette" wrote in message |> news: |> > James Kanze a écrit:
|> > >cedric writes:
|> > >|> Oui, mais je doute que sur un mainframe, par exemple, et ceci |> > >|> dit sans vouloir énerver personne, ladite fonction parvienne |> > >|> à convertir par ce moyen un caractère local en ascii ;) |> > >|> Disons que je trouve le nom de la fonction un peu trompeur.
|> > >Le nom n'est pas assez parlant. Dans ce cas-ci, toascii ne veut |> > >pas dire convertirToAscii, mais forceToAscii.
|> > Attention, ToAscii est une fonction (clavier) de winuser.h ;-) |> > J'ai regardé toascii() sur Google. Certaines définitions |> > n'utilisent même pas le mot "ascii", et quand il y est, il |> > n'explique rien de plus: c'est un masquage "& 0x7F". Le proto est: |> > int toascii(int);
|> > Remarquez, les fonctions normalisées de ctype.h qui elles sont |> > utiles ont le même proto.
|> toascii() servait à masquer le bit de parité, après lecture sur un |> port série par exemple ou la parité n'était pas gérée par le |> hardware. plus très utile de nos jours ;-)
Alors, qu'est-ce qu'il a, ou avait, à faire dans ctype.h ? Et pourquoi un nom aussi trompeur de toascii ? Ce genre de fonctionnement (encore utile dans certains cas particuliers) appartient au niveau système, mais dans ce cas-là, si je ne le fais pas directement en ligne dans le code, je l'appelle quelque chose du genre removeParityBit().
-- 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
