🚀 go-pugleaf

En <news:4342f7d1$0$1736$8fcfb975@news.wanadoo.fr>, Harpo va escriure:
> Antoine Leca wrote:
>
>> 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.

> Une des caract�ristique de l'alphabet ASCII est de tenir sur 7 bits,

Non. C'est le codage qui tient sur 7 bits.
Par alphabet (le terme correct est r�pertoire), je voulais dire l'ensemble
des diff�rents caract�res avec leurs significations, mais sans leurs
repr�sentations num�riques conventionelles.


>> En 16 bits, (unsigned)32769 aussi a le 'bit de gauche' � 1, il n'est
>> pas n�gatif pour autant.
>
> S'il est non sign� comment pourrait-il �tre n�gatif ?

(int)32769 l'est. Mais 0x8001 ne l'est pas.
Et c'est le m�me principe avec les char: quand tu en prends un qui est en
dehors du domaine de d�finition, il est possible qu'il soit n�gatif, avec
toutes sortes de probl�mes � la cl� si l'on ne fait pas attention.
Pour �viter ces probl�mes, en C les caract�res � du jeu de base � ne cr�ent
jamais ce probl�me ; soit parce qu'ils tiennent sur 7 bits et donc le bit de
poids fort est � 0 (pas de souci), soit si ce n'est pas le cas (EBCDIC)
parce que char est un type non sign�.


> Je vais donc parler de choses simples :
> Le fait que sur 2 plateformes, 1 code correct au niveau de la norme
> sur l'une ait un comportement diff�rent sur l'autre est un enjeu au
> niveau de la portabilit�.

La norme d�finit � correct � (strictement conforme) comme �tant le code qui
a un comportement identique sur toutes les plateformes...

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). Si le pro
grammeur fait des hypoth�ses sur les choix des compilateurs, le r�sultat
peut �tre soit des variations (comportement non sp�cifi� ou d�fini par
l'impl�mentation, ce qui est donc une restriction � la portabilit�), soit
n'importe quoi (les fameux comportements ind�finis, qu'il vaut mieux �viter
en pratique).


> Je suis renomm� pour �tre casse-couilles et un peu niaiseux, mais
> j'aime bien qu'on m'explique pourquoi lorsque je dis une connerie.

Je n'ai pas bien vu o� �tait la dite "connerie".
Tu as fait une extrapolation entre une information ('a' vaur 0x81 en EBCDIC)
et une autre (char est sign� sur ta plateforme), mais il se trouve que cette
inf�rence ne tient pas.

� partir de l�, on a essay� de te montrer le probl�me, et aussi pourquoi on
en est arriv� l�.


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


> Une des qualit�s accord�es au C est une assez bonne portabilit�, l�
> c'est vraiment du suicide.

Le fait est qu'ici, tu auras en g�n�ral moins de probl�mes de portabilit� (y
compris si tu vises des machines EBCDIC)avec le comportement sp�cifi� par la
norme.

Mais si tu extrapoles (genre d�cider d'utiliser des char comme � petits
entiers sign�s �, alors que ce n'est pas leur propos), effectivement il est
des fois o� cela ne fonctionne pas, � c'est du suicide �.


Antoine