🚀 go-pugleaf

En <news:4342ee56$0$27403$8fcfb975@news.wanadoo.fr>, Harpo va escriure:
> Pour moi un byte, c'est 8 bits (disons 'g�n�ralement' pour les
> puristes), le signe n'est qu'une abstraction.

Autrement dit, tu travailles en compl�ment � 2.


> Vers le milieu des ann�es 80,

Le langage C date du d�but des ann�es 70. � cette �poque, la situation
n'�tait pas aussi tranch�e que maintenant ou m�me qu'en 1985. Par exemple,
le premier compilateur C (PDP-11) avait des char sign�s sur 8 bits, codage
ASCII. Le second (IBM) avait des char non sign�s sur 8 bits, codage EBCDIC.
Le troisi�me (GECOS) des char non sign�s sur 9 bits, et Ritchie a choisi le
codage ASCII (cette machine manipulait aussi de l'EBCDIC).


> 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.

J'ai dans mon dos un AS/400. �videmment, les applications historiques
travaillent en EBCDIC en un langage (RPGII) qui ressemble � du PL/1. Mais
cette b�cane a aussi un support TCP/IP, un shell semblable � ceux de Unix ou
Windows, fait tourner des applis en Java etc., autrement dit il y a pas mal
de code C.

Je ne sais pas en quel langage est programm� DB/2, mais utiliser C pour cela
me semblerait logique.

Maintenant, les fichiers de cette b�cane sont pour la majorit� en EBCDIC.
Donc, un certain nombre de ces programmes en C ont �t� compil�s avec comme
jeu de caract�res l'EBCDIC.
Et le plus dr�le, c'est que cela marche tr�s bien. Y compris pour des
programmes issus du monde Unix, pas du tout pr�vus au d�part pour utiliser
autre chose que de l'ASCII...


> 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�.

Mmmmh.
Il est �ventuellement possible qu'au tout d�but (vers 1961-63), IBM ait eu
cette id�e ; mais en fait cela m'�tonnerait ; je pense que les ing�nieurs
d'IBM de l'�poque �taient vraiment convaincus que le jeu de caract�res
devait � coller � aux sp�cifications des cartes perfor�es, m�me si dans les
faits la plupart des lecteurs/perforateurs utilisaient d�j� des tables de
transcodage. Apr�s (vers 1963, quand la norme ASCII s'est cristallis�e),
c'est devenu plut�t de la bouderie devant le fait que le standard ne
reprenne pas les positions du leader de l'industrie (un peu comme la FSF qui
d�cide de r��crire tel ou tel utilitaire parce que le code de machinBSD ne
leur plaise pas, ou parce que Microsoft est m�l� de pr�s ou de loin � tel
autre. �videmment on peut inverser les noms dans la phrase pr�c�dente ;-).)
Dans les ann�es 70, IBM a peut-�tre utilis� sa _diff�rence_ afin de
verrouiller ses clients et donc d'augmenter ces marges, mais l� c'�tait de
la tactique, pas de la strat�gie ; d'ailleurs, aujourd'hui qu'il n'y a plus
gu�re d'avantage � utiliser EBCDIC, cela leur revient dans le dos, c'est
normal et m�me pr�vu. Dans les m�mes ann�es 70, DEC, qui n'avait pas de
contraintes li�es aux machines � cartes perfor�es existantes ni aux fichiers
en BCD, a choisi au contraire de basculer le plus possible vers l'ASCII et
les bytes sur 8 bits, l� encore par tactique, mais celle du challenger
(innovant).

Maintenant, pour ce qui est du C et des encodages pour char, l� il n'y a
certainement aucune volont� de bloquer, tout au contraire : Dennis Ritchie
avait � sa disposition en 1970-72 d'une part des PDP-11 qui causaient ASCII
sur 8 bits de pr�f�rence sign�s, d'autre part des machines GE/Honeywell qui
causaient soit ASCII soit (E)BCDIC sur 9 bits (en g�n�ral) de pr�f�rence non
sign�s (pas d'op�ration c�bl�e d'extension de signe) ; donc il y a laiss�
une certaine marge sur la d�termination de ce qu'est un char, sign� ou pas,
8 ou 9 bits.
La suite, c'est s�r que celui qui a eu du succ�s, c'est le premier des deux,
et le syst�me Unix qui allait avec. Mais la diversit� des machines du labo
de la Bell est rest�e incrust�e dans le langage. Au moment de la norme ANSI,
dans les ann�es 80, les normalisateurs (suivant l'exemple du bouquin, le
K&R1) n'ont pas d�rog� � cette r�gle, m�me s'il devenait de plus en plus
�vident que la tr�s grande majorit� utilisait des char sur 8 bits encod�s en
ASCII (pour le signe, il y avait plus de variabilit�). Et aujourd'hui c'est
trop tard pour revenir en arri�re l�-dessus, cf. ce que j'�crivais au-dessus
sur le code en C �crit ou port� par IBM et consorts (largement apr�s la
publication de la norme), sur une machine EBCDIC.


Antoine