🚀 go-pugleaf

En <news:43411501$0$27446$8fcfb975@news.wanadoo.fr>, Harpo va escriure:
> D'abord, qui c'est �ui l� encore le 'basic execution character set' ?

Les caract�res juste suffisant pour programmer en C.
En gros, � l'alphabet � ASCII, dont on exclut '$' '@' et '`' des caract�res
graphiques, et dont on garde seulement '\0' (qui ne veut plus dire NUL),
'\a' (BEL), '\t' (HT), '\f' (FF), '\v' (VT) et '\r' (CR) dans les caract�res
de contr�le, et auquel on ajoute enfin '\n'.


> Je croyais na�vement qu'un char �tait un integer comme un autre, un
> peu petit pour son �ge, c'est tout. 129 ( 0x81 ) a le 'bit de gauche'
> � 1, je pensais qu'il �tait n�gatif.

En 16 bits, (unsigned)32769 aussi a le 'bit de gauche' � 1, il n'est pas
n�gatif pour autant.

La subtilit�, c'est que char peut �tre soit sign�, soit non sign�, suivant
l'architecture sous-jacente. Sur le PDP-11 (qui avait pas mal d'instructions
pour manipuler des entiers 8 bits sign�s), c'est signed. Sur la grande
majorit� des autres machines de l'�poque), c'est unsigned, soit pour assurer
la compatibilit� EBCDIC, soit parce qu c'est plus r�gulier au niveau du jeu
d'instructions.

Ensuite, sur le Vax c'est rest� signed, et de l� cela c'est propag� jusque
dans la norme. Les compilateurs pour des architectures CISC (qui sont assez
insensibles aux d�tails du jeu d'instructions) ont en g�n�ral une option
permettant de choisir si char est sign� ou pas.


> Pour m'�claircir les id�es, j'ai fait ce petit programme en C.
> Le r�sultat a �t� conforme � mes attentes :
> 129 = -127

C> a
129 = 129
C> gcc -v
Reading specs from bin/../lib/gcc/mingw32/3.4.2/specs
[...]
Thread model: win32
gcc version 3.4.2 (mingw-special)

Et je n'ai pas compil� crois� pour l'AS/400, ni m�me avec une version
sp�ciale de libc. Seulement
C> gcc --unsigned-char -W -Wall uchar.c



> Maintenant, veux-tu dire que si j'avais compil� sur un bon vieil IBM
> pour qui ASCII est un mot de 5 lettres, j'aurais obtenu ce r�sultat
> aberrant :
> 129 = 129
> ?
> Parce que son 'basic execution character set' serait diff�rent ?

D�pend de quel c�t� tu te places. Du point de vue du C, non, il n'est pas
diff�rent, il se constitue aussi de '\0', '\n', '!', 'a' etc. �videmment,
'a' vaut 0x61 sur une machine et 0x81 sur l'autre. Mais si tu r�fl�chis un
peu, ce n'est pas beaucoup plus diff�rent que la situation de '�', qui vaut
0xA4 ici, 0x20AC l�, 0x80 l� bas ou 0xD5 chez IBM. Enfin, chez IBM on trouve
aussi 0x9F, et aussi 0X5A chez les Scandinaves.



> Qui a pondu cette norme qui m'�nerve les nerfs ? C'est une atteinte
> d�lib�r�e � la portabilit� !

C'est une atteinte � TA vision de la portabilit� (qui doit ressembler � �
cela marche chez moi et cela doit marcher partout �). Comme la libert� des
uns s'arr�tent o� commencent celles des autres, la r�alit� est un _peu_ plus
complexe.


> Sans vouloir refaire le C ni m�me le reste du monde, je pense que tout
> aurait �t� plus simple si tout avait �t� unsigned par d�faut.

Non. Le prix � payer �tait trop important sur un PDP-11 (l'anc�tre duquel
tout d�pend). Et c'est comme dans les histoires de machines � remonter le
temps : si tu changes l'anc�tre, il n'y a plus de langage C. Du tout.
En fait, c'est parce que Dennis Ritchie devait tergiverser avec les
contraintes d'extensions de signe du PDP-11, et que par ailleurs sur EBCDIC
(l'autre machine sur laquelle il d�veloppait) les char �tait n�cessairement
non sign�s, que le C a pu � facilement � accomoder n'importe lequel des
encodages qui sont venus par la suite (et simultan�ment), y compris les
encodages multibytes (il n'y a gu�re que Unicode avec l'utilisation des
octets � 0 qui pose r�ellement probl�me).


> uchar est-il dans la norme ?

Non, c'est un identificateur r�serv� au programmeur, et c'est tellement
utilis� que ce n'est pas pr�t de changer ;-)


Antoine