🚀 go-pugleaf

"Harpo" <trashcan@hotmail.com> wrote in message
news:4342ee56$0$27403$8fcfb975@news.wanadoo.fr...
> Antoine Leca wrote:
>
> > En <news:4340d2c9$0$27410$8fcfb975@news.wanadoo.fr>, Harpo va
> > escriure:
> >> Charlie Gordon wrote:
> >>
> >>> le cast en (int) de alphabet[i] est inutile, il ne fait rien du
> >>> tout, de plus alphabet[i] est forc�ment positif, donc inutile de
> >>> caster en (unsigned char).
> >>
> >> C'est vrai en ASCII, pas en EBCDIC.
> >
> > Ah bon ? Tu peux me d�crire comment tu arrives � cette conclusion ?
> >
> > Si 'A' (0xC1 en EBCDIC) �tait n�gatif, tu casserais tellement de code
> > aux �tats-Unis que ce n'est m�me pas une hypoth�se vraissemblable sur
> > la DS9000.
>
> Je ne sais pas, j'ai travaill� assez longtemps sur des machines IBM en
> EBCDIC, le signe des caract�res ne m'a jamais beaucoup travaill�, tr�s
> g�n�ralement on ne fait pas de grands calculs sur 8 bits, m�me dans des
> banques qui d�marrent avec un petit capital.
> Pour moi un byte, c'est 8 bits (disons 'g�n�ralement' pour les
> puristes), le signe n'est qu'une abstraction.

Pas vraiment : si les caract�res du jeux de base �taient n�gatifs, cela
casserait un paquet de code.
Imaginons par exemple une machine o� les byte feraient 8 bits, les char seraient
sign�s par d�faut et qui utiliserait le jeu de caract�res EBCDIC : sur une telle
machine l'expression suivante serait toujours fausse:

getchar() == 'A'

> Vers le milieu des ann�es 80, IBM a commenc� � s'int�resser � Unix et au
> C, on peut dire ce qu'on veut il n'y a pas que des porte-cravate chez
> eux, � ce moment ils n'avaient aucun code � casser en C, puisque tout
> �tait �crit en assembleur, PL/1, ou Cobol pour les applications chez
> les clients.

Pour y "supporter" Unix, ils n'ont pas tout r��crit, ils se sont content�s de
porter et d'�tendre le code d'ATT sous license.
Il y a fort � parier que le code original d'Unix fait la supposition que les
caract�res du jeu de base sont positifs.

> Cette histoire de 'machin character set' n'ob�it pas � une n�cessit�
> technique mais me semble plut�t venir d'une strat�gie commerciale qui
> vise � isoler la client�le en creusant un foss� avec la concurrence par
> la non-portabilit�. Pour moi c'est une strat�gie de minable, IBM semble
> l'avoir d�laiss�e, Microsoft s'y adonne encore.

D'accord sur la conclusion, mais les faits sont t�tus :EBCDIC n'est-il pas
ant�rieur � la normalisation de ASCII par l'ASA ?

http://en.wikipedia.org/wiki/ASCII :
ASCII, invent� par les Bell Labs (comme unix ;-) fut normalis� en 1963 en 6 bits
(pas de minuscules), puis en 1967 avec les minuscules.
Je me souviens d'avoir utilis� des machines avec les fl�ches vers le haut et la
gauche � la place des ^ et _ ce qui ne me rajeunit pas ;-)
Les Bell Labs utilisaient le ruban perfor�, avec 5, puis 6, 7 et enfin 8 trous
par ligne, avec bit de parit�.  Donc les caract�res devaient �tre group�s sur 7
bits au plus.

http://en.wikipedia.org/wiki/EBCDIC :
EBCDIC, invent� pas IBM en 1963 aussi utilisait 8 bits d�s le d�part. avec une
gen�se fortement marqu�e par les choix techniques pour les cartes perfor�es...
qui comportaient 12 positions de trous par colonne (et g�n�ralement 80
colonnes), sans bit de parit�, mais en privil�giant les combinaisons de 2 ou 3
trous maximum.

IBM a gard� longtemps ce syst�me, alors que ASCII progressait chez ses
concurrents.  je ne pense pas qu'ils aient eu une volont� d�lib�r�e d'isoler
leurs clients comme tu le dis, le choix fait pour le PC par Microsoft, sans
aucun doute command� par la compatibilit� CP/M, et le manque de vision d'IBM
pour ce qu'ils consid�raient comme une calculatrice sans grand avenir ont permis
� ASCII de s'imposer.  C'est donc Gary Kildall (
http://en.wikipedia.org/wiki/Gary_Kildall )  qu'il faut remercier un fois de
plus, paix � ses cendres.

-- 
Chqrlie.