Godzil (./2) :
Sa a un sens, dans le sens ou peut etre qu'un bout de code pourrait faire "Failed_State = 42;" (ce qui serait farpaitement valide)

Peut-être, mais pour moi ça ne provoquerait pas forcément l'activation de la condition, si ?

Godzil (./2) :
D'ailleur le code est a mon sens assez idiot, meme si ce n'est que dans des cas tres rare de compilo completement idiots, mais (0 == 1) pourrai tres bien provoquer que le compilo faite le test a chaque fois que l'ont utilise "FALSE", donc perte de vitesse mais bon

On s'en fout de la rapidité du code. Pour des raisons évidentes de traçabilité du code source vers le code objet, les optimisations sont désactivées, et la norme interne précise:

Rule 12.6 For Boolean value, TRUE and FALSE shall be defined by evaluation obviously false and obviously right.

For example, TRUE must be defined by a test obviously TRUE as (1==1) and FALSE as (1==0) and then the compiler define the Boolean value.

TRUE and FALSE must not be defined by constant because in C language only FALSE is known as 0. TRUE is a value different of 0.

Le but est justement de ne pas laisser à l'utilisateur définir numériquement TRUE et FALSE, même en faisant 0 et !0

Godzil (./2) :
sinon (mais bon ça depend de ce que veux le gars et le soft) normalemetn en C (et je suis presque sur que c'est dans la norme) la valeur 0 est toujours associé a true, et tout ce qui est différent de 0 est false...

donc TRUE = 0
FALSE = !TRUE

(c'est la notation que je préfère a vrai dire )

Nan, c'est l'inverse

Godzil (./2) :
En meme temps le code a un sens, on ne veux que ces deux valeurs, toutes les autres son considéré comme parasite et provoquerons une erreur...

cf plus haut, on n'a pas 0 et 1 ici...

Godzil (./2) :
N'oublie pas que la il travail avec un uchar, donc un entier sur 8bit, donc 256 valeurs possible...

Oui mais je ne vois pas en quoi on serait ici dans un cas différent au final du 0 et !0 en fait ...