Des cas de bugs avaient été répertoriés faisant état de variables témoin incrémentées ou décrémentées ; au bout de 255 passages dans une boucle la variable retrouvait l'autre état (0) et évidemment, cela avait des conséquences...
Pour une description complète des conséquences potentielles d'un dépassement de capacité, on pourra lire :
http://www.astrosurf.com/luxorion/astronautique-accident-ariane-v501.htm
Pour ceux qui sont pressés, lire en particulier les paragraphes "O" et "P" de la conclusion.
Je note néanmoins que tous les auteurs des formules publiées ci-dessus ont indiqué les conditions de fonctionnement de leurs expressions.
SI on respecte le contexte d'utilisation, aucune d'entre elles ne peut provoquer un dépassement de capacité.
Dans le cas cité ci-dessus, c'est bien l'utilisation d'un programme dans un contexte inapproprié (ou la non-modification du programme pour prendre en compte le nouveau contexte) qui a conduit à la catastrophe.
L'utilisation de fonctions booléennes ne constitue aucunement une garantie si on ne tient pas compte du contexte spécifié.
Par exemple, pour l'expression proposée par MGU :
var est spécifié de type bit.
Mais si on oublie ce contexte et que l'on utilise un byte :
si var=0 alors "var=nor var" donne 255
et si var=1 alors "var=not var" donne 254...
C'est pour être indépendant du type de la variable que j'ai proposé l'expression :
A=1-A
Mais évidement il faut quand même respecter le contexte proposé, à savoir initialiser la variable à zéro ou à un.