Discussion :

[nico-pyright(c)]

enfin c'etait aussi parce qu'on est passé de compilos 16 bits a 32 bits..

oui bon, j'avoue, je me fais l'avocat du diable ...
mais qui a dit que la prudence était une mauvaise chose ?

[damien99]

Si notre table de caratère (aujourd'hui 256 car.) vient à s'agrandir, alors je pense que on peut refaire tout les programmes actuels pour qu'il soit compatible...
Faut quant même pas oublier que c'est toujours la même depuis le début de l'informatique (enfin je croi tout du moins depui l'époque de DOS), et je pense pas quelle va changer, d'autant plus que j'en vois pas la nescesité avec l'invention des polices on peut avoir une infinité de caractères

EDIT: changer un tel truc dénaturerait l'unité de l'octet...

[damien99]

Je vient de voir qu'il y a un bug dans l'algoritme qu'on avait trouvé

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

nombre = chaine[0] | (chaine[1] << 8);

Quant un "char" est plus grand que 128 il renvoi un chiffre négatif par exemple si on met :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

char car=255;   //car!=255 mais car==-1 (Le bug vient de là)

Je regarderai ça dès que j'aurait le temps, sauf si quelqu'un a deja trouvé la solution avant moi

[nico-pyright(c)]

il faut utiliser unsigned char dans ce cas

[damien99]

Je savais pas que ça servait a ça les unsigned.

Vous foutez pas de moi, moi j'ai pas de professeur j'apprend tout seul pendant les vacances, donc j'apprend pas forcement les choses dans le bon ordre....

[ekinox17]

me semble que l'on peut remplacer le typer unsigned char par BYTE
c'est plus propre je trouve
portée d'un unsigned char (BYTE) : 0 > 255
portée d'un char : -128 > 127