"Check that the boolean is a real one" - Page 1

typedef unsigned char Boolean_t
[...]
#define FALSE ((Boolean_t)(0 == 1))
#define TRUE  ((Boolean_t)(0 == 0))
[...]
Boolean_t Failed_State
[...]
/* Check that the boolean is a real one */
if ((Failed_State != TRUE) &&
    (Failed_State != FALSE))
{
    SHUTDOWN_BECAUSE_BAD_INPUT_M();
}

Il y aurait-il une subtilité qui m'échapperait et qui justifierait ce bout code ?
(non ça n'est pas destiné à un processeur quantique)

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)

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

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 )


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

N'oublie pas que la il travail avec un uchar, donc un entier sur 8bit, donc 256 valeurs possible...

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

Ximoon (./3) :

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

Oui je m'a suis gourré

Surtout que c'est plus marrant dans ce sens

FALSE = 0
TRUE = !FALSE

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

(Ok pour votre norme, et je comprend tres bien le pourquoi du comment)

Et si tu as 2 valeurs qui sont 0x00 et 0xFF et c'est le meme problème que si c'était 0 ou 1. Vous travaillez avec un entier pouvant contenir 256 valeur, et seul 2 sont significatives (0x00 aka 0 aka 0==1 et 0xFF aka !0 aka 0==0)

toutes les valeurs [0x01;0xFE] ne sont ni "TRUE" ni "FALSE" et ne doivent pas etre accepté car dans ton code si tu fait

Failed_State = TRUE

if (Failed_State == FALSE)
{
// faire ce qui fait pour "FALSE"
}
else if (Failed_Stat == TRUE)
{
// faire ce qu'il faut pour "TRUE"
}

Ton code marchera tres bien quand Failed_State sera egal a TRUE ou FALSE, mais ne ferra rien dans les 254 autres valeurs possibles...

Donc si tu as un "Failed_State = 42" qui apparaitrait au milieu entre le "= TRUE" et le if je te laisse imaginer ce qui pourrais se passer.

Bon la le code est peut etre inutile et "trop protecteur" (cad que les 254 autres valeurs ne peuvent "code-ement" parlant pas apparaitre mais bon..

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

Cf plus haut ^^

(ps: en ./2 le c'est le code en lui meme hein je trouve ça aussi tres "marrant")

Godzil (./4) :
Ton code marchera tres bien quand Failed_State sera egal a TRUE ou FALSE, mais ne ferra rien dans les 254 autres valeurs possibles...

Donc si tu as un "Failed_State = 42" qui apparaitrait au milieu entre le "= TRUE" et le if je te laisse imaginer ce qui pourrais se passer.
Bon la le code est peut etre inutile et "trop protecteur" (cad que les 254 autres valeurs ne peuvent "code-ement" parlant pas apparaitre mais bon..

Ouais effectivement, après test (sous borland pour x86) le compilo met 0 et 1 pour FALSE et TRUE dans ce cas (j'imagine que ça peut changer selon les processeurs et les compilateurs), donc ça permet effectivement de s'assurer que l'utilisateur n'a pas mis de valeur numérique personnelle à la place de TRUE et FALSE... J'avoue que je m'attendais à un autre comportement en fait.

Godzil (./4) :
(ps: en ./2 le c'est le code en lui meme hein je trouve ça aussi tres "marrant")

J'avais bien compris

0 et 1 ? c'est bizzare... ça devrait plutot etre 0 et 255

Godzil (./6) :
0 et 1 ? c'est bizzare... ça devrait plutot etre 0 et 255

Je ne vois pas pourquoi Pour les tests sur les booléens, 1 et 255 font aussi bien l'affaire l'un que l'autre, du moment que c'est différent de 0...

c'est heu... ?

c'est au cas ou un developpeur mal reveille modifierait les macros TRUE et FALSE !
comme ca, ca le previent qu'en fait non, c'est pas bien de faire ca...

Surtout qu'elles sont définies dans les bibliothèques standard du département, donc en lecture seule

( tu m'as donné envie de siester toi )

Ximoon (./7) :

Godzil (./6) :
0 et 1 ? c'est bizzare... ça devrait plutot etre 0 et 255

Je ne vois pas pourquoi Pour les tests sur les booléens, 1 et 255 font aussi bien l'affaire l'un que l'autre, du moment que c'est différent de 0...

Ben simplement parce que 255 c'est le complement a 1 de 0, donc c'est l'inverse total de 0 (aka 0b00000000 vs 0b11111111, donc (TRUE == !FALSE) && (TRUE == ~FALSE))

Ximoon (./3) :

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 ?

Ben si

Moi ça me paraît pas du tout aberrant comme test... (même si ce serait mieux si c'était fait de manière statique, ou bien s'il n'y avait jamais de comparaisons avec TRUE et que donc toutes les valeurs non nulles étaient rigoureusement équivalentes pour tout le reste du code -- mais si on en est pas sûr, c'est plus prudent de vérifier)


et euh sinon la norme C garantit que 0==1 vaut 0, et que 0==0 vaut 1 ^^ (donc c'est pas possible que TRUE vaille 255)

Oui, mais ça n'a strictement aucune importance, ça aurait très bien pu être 14, 31 ou 42... En l'occurence "1" permet de faciliter l'arithmétique sur les booléens (je crois que c'est normalisé ça, mais j'ai pas été voir moi-même ): genre x = i + (y==0), où (y==0) devrait valoir 1 si vrai, 0 sinon. Qui a dit crade ? Je crois que c'était un italien bien connu qui se ventait d'utiliser ce genre de code, à vérifier.

Cross: ouais en fait ça rejoint ce que je dis dans le présent post donc je le savais mais j'avais pas fait le lien

Pollux (./11) :
et euh sinon la norme C garantit que 0==1 vaut 0, et que 0==0 vaut 1 ^^ (donc c'est pas possible que TRUE vaille 255)

ben rien que pour faire chier je vais faire un Po2cc255 ou true = 255

nan mais

C'est vrai que l'instruction Scc d'un 68k met l'octet correspondant à 255 et qu'un test vrai renvoi -1 au lieu de 1 en BASIC Amstrad, mais en C, il en a été défini autrement...

Évidemment, pour Scc je parlais d'un test vrai...
Ou bien, ma doc n'est pas à jour:

Ma doc :
Scc d : Si cc vrai, $FF --> d, sinon $0 --> d

Quant à l'autre partie de ma phrase, elle n'a rien à voir avec les TI, puisqu'il s'agit de BASIC Amstrad.
si tu écris:

10 a=42
20 b= 2+(a=42)

Le test "a=42" sera vrai et la valeur sera -1, b sera donc égal à 1.
(enfin, je dis ça de mémoire).