🚀 go-pugleaf

Pierre Maurette wrote:

>> Serait tu d'accord pour dire qu'il est pr�f�rable de d�clarer
>> explicitement les char comme signed ou unsigned  d�s qu'il y a le
>> moindre risque qu'il y ait des effets diff�rents selon leur signe.

> J'essaie de m'en tenir � la r�gle suivante: si le char est un
> caract�re, une lettre, il reste un char.

Oui, mais dans une chaine destin�e � contenir des caract�res, on peut
recevoir un peu de tout et une 'lookup table' des caract�res permis
peut �tre un moyen de la contr�ler assez rapidement, si le byte est
tant�t unsigned, tant�t signed en fonction de la plateforme et de son
'basic execution character set', �a devient p�rilleux.
Je pense qu'il est plus prudent d'utiliser uchar lorsqu'on traite du
texte, et soit uchar soit schar dans les autres cas suivant l'usage
qu'on fait des bytes.

> Si c'est un entier, je d�finissais sbyte et ubyte, avec parfois des
> variantes, en particulier si j'en connais n�cessairement la taille.
> J'utilise de plus en plus quand c'est possible les uint8_t et int8_t.
> J'aurais pr�f�r� sint8_t.
> Mes choix de noms sont peut-�tre discutables, mais j'aime bien ne
> nommer cher que des caract�res.

Oui, c'est surtout int�ressant lorsque la taille des bytes est
importante et pour une architecture (pas rarissime) o� les bytes font 8
bits.
sint8_t aurait aussi, ama, �t� pr�f�rable � int8_t s'il est d�fini comme
ou �quivalent � signed char sur des machines ou le byte fait 8.

> 
>> J'ai aussi pens� �
>> #define char unsigned char
>> Mais en y r�fl�chissant 2 minutes c'est tr�s con.

> Les r�actions des compilateurs sont vari�es.

C'est surtout que beaucoup de fonctions de librairies attendent des 
char * comme argument.
Quand au pr�processeur, il ne semble pas chez moi r�cursionner pour une
m�me macro. Je ne sais pas si c'est une attitude normalis�e.
#define char unsigned char
donne le r�sultat souhait�.
Par pur vice, j'ai aussi essay� :
#define char unsigned foo
#define foo char
Ils y ont bien s�r pens�...