🚀 go-pugleaf

Antoine Leca wrote:

> 
>> Une des caract�ristique de l'alphabet ASCII est de tenir sur 7 bits,
> 
> Non. C'est le codage qui tient sur 7 bits.

Ok, mais si on cherche la petite b�te on peut aussi dire que leur codage
*peut* tenir sur 7 bits. Amha, quand on parle d'ASCII on ne parle en
g�n�ral pas d'un alphabet mais d'un codage.

(...)

> 
> Le reste, c'est-�-dire la quasi-totalit� des programmes utiles ;-),
> n'a pas de comportement pr�cisement d�fini par la norme, c'est livr� �
> la libert� d'interpr�tation des compilateurs; les compilateurs ont des
> contraintes (genre char 8 bits doit �tre non sign� en EBCDIC, et peut
> �tre sign� ou pas en ASCII), et des libert�s (ils peuvent utiliser
> ASCII ou EBCDIC).

Cela n'appara�t pas clairement dans la partie de la norme que tu a
montr�.
Si un character du 'basic execution character set' peut �tre non-sign�,
voire positif, alors que, comme en EBCDIC, son bit de poids fort est �
1, il n'apparait pas clairement qu'il est n�cessaire que tous ce qui a
un bit de plus fort poids � 1 doit �tre non sign� ou positif, il
n'apparait pas clairement dans la norme, que dans un codage du style
EBCDIC dans lequel 'a' vaut 0x81 et est non-n�gatif, 0x80 qui
n'appartient amha pas au 'basic execution character set' doit l'�tre.
Ok, celui qui ferait une telle impl�mentation devrait �tre donn� �
manger aux canards, mais quand on lit une norme il faut s'abstenir de
voir autre chose que ce qu'elle dit.

(...)

> 
>> La norme laisse sous-entendre que l'on peut �crire un code
>> correspondant � la norme sur une plateforme qui ne marchera pas sur
>> une autre.
> 
> Pr�cise ta pens�e, s'il te pla�t.

Si j'utilise un byte en l'appelant char sur une plateforme pour laquelle
il est non-sign� et que je m'en serts comme offset dans une table cela
marchera, cela ne marchera pas sur une plateforme ou char est sign�
lorsque ce char sera n�gatif.