Les spécifications des normes respectives des langages C et C++ sur les types entiers sont difficiles à comprendre pour un codeur débutant. Au motif d'une forte compatibilité avec l'évolution historique des langages, elles imposent des contraintes minimales de taille tout en laissant une certaine liberté d'implémentation (cf. chap. C1‑II ).

Pour des questions pédagogiques, il est préférable de ne pas trop insister sur ces contraintes normalisées et d'aborder la variété des types entiers de façon pragmatique, au regard des implémentations les plus courantes, en particulier celles basées sur les chaînes de compilation GCC.

L'attribution d'un type à une constante littérale détermine le nombre de registres requis dans le CPU pour effectuer un calcul avec cette donnée. La stratégie de compilation consistant à attribuer à toute valeur entière un type de taille au moins aussi grande que celle du type int permet de diminuer les risques de débordement des limites minimales et maximales lors de l'évaluation des expressions calculatoires.

Les débordements d'entiers et leurs conséquences sont expliqués infra . Des éléments pour leur prévention sont apportés au chapitre C3‑VI .

Séparateur digital

int a = 5'000'000;        // 5 millions
short b = 0b10'0111'1111; // 639

Algorithme de conversion de la base 10 vers la base 2

En notant comme ci‑dessous, pour k allant de 0 à n − 1, l'équation fondamentale de la k‑ième division euclidienne par 2 :
D_k  =  2.q_k + r_k
et sachant que les dividendes D_k et les quotients q_k sont liés par la relation :
D_k + 1 = q_k   (avec   D₀ = x)
alors les n bits d_k du code binaires de x sont, dans l'ordre de leur rang k croissant, les restes successifs r_k de chaque division, comme illustré sur la figure ci‑contre.

La conversion en base 2 du nombre entier 14 est illustrée par la figure ci‑dessous, avec :

• à droite la succession des divisions euclidiennes posées en cascade ;
• et à gauche la mise en équation de ces divisions, qui permet de reconstituer la valeur 14 comme une somme discrète de puissances croissantes de 2.

Il existe différents formats binaires d'encodage des entiers signés, mais celui dit du « complément à 2 » est presque universellement employé W. Les autres (complément à 1, signe‑magnitude) sont désuets ; néanmoins, ils restent autorisés par les normes des langages C et C++, au motif de garantir leur compatibilité avec d'anciennes implémentations.

Exemples pratiques de débordements d'entiers

Un débordement inopiné peut résulter de diverses erreurs de codage et avoir des conséquences négatives. Les exemples proposés ci‑après n'ont rien d'exhaustifs, mais sont assez « classiques » chez les programmeurs débutants.

• Le cas le plus trivial est celui de l'affectation directe dans un type sous‑dimensionné (ou avec une valeur sur‑dimensionnée, selon un point de vue complémentaire) ;

Dans un programme pour carte Arduino, la déclaration ci‑dessous emploie un grossière erreur de typage (sous‑dimensionnement) mais heureusement détectable par compilateur (donc signalée par un avertissement) :

const uint8_t BLINK_HIGH_DURATION = 300; // error: UINT8_MAX == 255! 

En effet, lors de son évaluation, l'expression constante 300 se voit attribuer automatiquement le type int (taille 2 octets sur une architecture 8 bits), avec l'encodage binaire :



Mais lors de l'affectation à la variable highDuration de type uint8_t (taille 1 octet) :

• seul l'octet de poids faible (least significant byte ou LSB) est stocké et il encode seulement la valeur 44 (32 + 8 + 4) ;
• quant à l'octet de poids fort (most significant byte ou LSB), il est perdu.

La solution à ce problème est évidemment très simple : il suffit par exemple de déclarer la constante BLINK_HIGH_DURATION dans le type uint16_t.

• Un cas moins flagrant – mais néanmoins courant – est celui du codage d'une expression dont l'évaluation produit une valeur beaucoup plus grande que celle de ses atomes, au point de déborder du type automatiquement choisi par le compilateur pour cette évaluation.

Toujours pour une architecture 8 bits, la ligne nº 12 ci‑dessous emploie un type sous‑dimensionné, mais cette fois l'erreur n'est pas détectée par le compilateur.

const unsigned BLINK_PERIOD = 1000;    
const unsigned DUTY_CYCLE_PERCENT = 75; 
const unsigned BLINK_HIGH_DURATION = (BLINK_PERIOD * DUTY_CYCLE_PERCENT) / 100; // error: UINT_MAX == 65535
const unsigned BLINK_LOW_DURATION =  BLINK_PERIOD - BLINK_HIGH_DURATION;        // cascading error

En effet, avec les valeurs des constantes déclarées ci‑dessus, la sous‑expression codée :
BLINK_PERIOD * DUTY_CYCLE_PERCENT
prend la valeur 75000 qui dépasse la limite supérieure du type unsigned (65535) dans lequel elle est évaluée. Et y remédier n'est pas simple si l'on se tient aux éléments de langage étudiés jusqu'à présent :

• il est inutile de changer le type de la constante BLINK_HIGH_DURATION puisque l'erreur se produit avant toute affectation ;
• il est inutile également de coder les suffixes LU à la constante 100 puisque celle‑ci est traitée après évaluation de la sous‑expression problématique ;
• il est impossible de changer le parenthésage en codant l'expression :
  BLINK_PERIOD * (DUTY_CYCLE_PERCENT / 100)
  car la division euclidienne 75/100 donnerait la valeur 0 !

Il serait bien entendu préférable d'utiliser un type décimal pour exprimer le rapport cyclique. cependant, il existe aussi une solution simple par conversion explicite. Elle sera présentée au chapitre C3‑VI .

• Enfin, un cas bien plus « vicieux » de débordement est celui de l'incrémentation (ou la décrémentation) d'une variable d'itération jusqu'à une limite d'étendue de son type.

1. Dans la boucle for ci‑dessous, le typage de la variable d'incrémentation ledLight est trop juste :

  for (uint8_t ledLight = 0; ledLight <= 255; ledLight++) {

En effet, à la fin de la supposée dernière itération de la boucle, la variable ledLight est incrémentée une dernière fois pour dépasser 255 et invalider la condition de répétition. Toutefois :
• son type ne lui permet pas d'atteindre la valeur 256 ;
• elle déborde et repart donc à 0.
Et ainsi, la boucle for est réinitialisée ! Elle se répète donc sans fin…
Ici, la solution est simple : il suffit de déclarer ledLight dans un type de plus grande taille (uin16_t par exemple).
2. Un problème analogue se pose avec la variable de décrémentation attempt de la boucle for ci‑dessous :

  for (uint8_t attempt = 10; attempt >= 0; attempt--) {

Parce qu'elle déclarée de type non signé, la variable attempt ne peut pas être décrémentée jusqu'à la valeur -1 pour invalider la condition de répétition de la boucle. Après avoir atteint la valeur 0, elle repart à 255 et la boucle for s'exécute sans fin…
Là encore, il existe une solution simple : il suffit donc de déclarer attempt de type signé int8_t.

Les débordements d'entier n'empêchent pas forcément d'évaluer de façon cohérente une soustraction de la forme a - b où les opérandes a et b sont de types non signés de même taille. En effet, même lorsque la valeur de l'opérande a déborde de la valeur maximale encodable et reboucle, la différence reste cohérente.

C'est en particulier le cas avec les fonctions millis et micros de la bibliothèque Arduino lorsqu'elles sont appelées dans un algorithme réactif de temporisation comme celui proposé au chap. C2‑IX  pour faire clignoter une led sans recourir à la fonction delay, reproduit ci‑dessous :

void setup()
{
  pinMode(LED_BUILTIN, OUTPUT);
}

unsigned long previousMillis = millis();
const unsigned BLINK_HALF_PERIOD = 1000; // = 1 s

void loop()
{
  if (millis() - previousMillis >= BLINK_HALF_PERIOD) {    // end of the half period
    previousMillis += BLINK_HALF_PERIOD;
    digitalWrite(LED_BUILTIN, !digitalRead(LED_BUILTIN)); // LED blinks
  }
}

Analysons ce qui se produit lors d'un débordement de la fonction millis, sachant qu'ici la led doit changer d'état toutes les secondes (donc toutes les 1000 ms).

• On rappelle que la valeur retournée par millis est encodée dans le type unsigned long dont la valeur maximale ULONG_MAX vaut 2³² − 1, soit 4 294 967 295.
• Donc par exemple, au bout de 4 294 968 secondes (soit 49 jours, 17 heures, 2 minutes et 42 secondes) :
• lors de l'exécution de la ligne nº 11, la valeur retournée par l'appel millis() devrait valoir 4 294 968 000 mais par limite d'encodage, elle reboucle à la valeur 704 (en arithmétique cyclique module 2³², c'est le résultat de la soustraction 4 294 968 000 − 4 294 967 296) ;
• quant à la valeur de previousMillis, elle vaut encore 4 294 967 000 car elle n'a pas changé depuis son incrémentation à la seconde précédente.
• La différence millis() - previousMillis vaut donc en théorie :
  704 − 4 294 967 000  =  −4 294 966 296  =  1000 modulo 2³²
  En effet, une valeur négative n'est pas encodable en mémoire dans le type unsigned long, mais imaginons qu'elle soit encodée dans le type long long, donc en complément à 2 sur 64 bits. Son écriture binaire serait :

  11111111 11111111 11111111 11111111 00000000 00000000 00000011 11101000

Dans la pratique, le registre de sortie du microcontrôleur opérant dans le type unsigned long, donc sur 32 bits, tronque cette valeur en ne gardant que les 4 octets de poids faible. Le résultat de la soustraction se réduit donc à la valeur binaire :

                                      00000000 00000000 00000011 11101000

qui correspond en base 10 à la valeur 1000, soit précisément la valeur attendue ! On voit donc à travers cet exemple que la soustraction de valeurs de même type est robuste au rebouclage.

Fonctions de génération de nombres pseudo‑aléatoires

Une machine informatique étant fondamentalement déterministe, elle ne peut pas engendrer des nombres aléatoires au sens strict du terme, du moins en principe. C'est pourquoi on parle de nombres pseudo‑aléatoires W.

La fonction rand

Génération d'un nombre pseudo‑aléatoire borné

Sur un ordinateur, pour simuler le résultat produit par 20 lancés consécutifs d'un dé à 6 faces, on peut coder le programme ci‑dessous :

#include <stdio.h> 
#include <stdlib.h> 

int main(void)
{ 
  for (int roll = 1; roll <= 20; roll++) {
    printf("%d ", 1 + rand() % 6);
  }
  return 0;
}  

6 6 5 5 6 5 1 1 5 3 6 6 2 4 2 6 2 3 4 1

Maîtrise du caractère aléatoire de la fonction rand

La fonction rand est usuellement implémentée par un générateur congruentiel linéaire W, c'est‑à‑dire une suite entière récurrente :

• dont le terme courant X_n dépend de X_n − 1 mais en diffère fortement, au point de former une séquence pseudo‑aléatoire de nombres entiers ;
• et qui est paramétrée par son premier terme X₀ qu'on appelle la graine (en anglais, seed) du générateur.

Afin que la graine soit différente à chaque exécution, il est d'usage, si la machine cible est un ordinateur, de recourir à la fonction time issue du fichier d'en‑tête time.h de la bibliothèque standard du langage C (ctime en C++) – cf. chap. C2‑IX .

Dans la plupart des implémentations, lorsque la fonction time est appelée avec pour argument la valeur NULL, elle retourne la valeur du timestamp Unix (nombre de secondes écoulées depuis le 1^er janvier 1970 – cf. chap. R2‑VI ) du système d'exploitation de la machine au moment de son exécution. Cette valeur est donc forcément différente à chaque nouvelle exécution du programme, en partant du principe qu'il s'écoule toujours au moins une seconde entre deux exécutions.

#include <stdio.h> 
#include <stdlib.h> 
#include <time.h> 

int main(void)
{
  srand(time(NULL)); 
  for (int roll = 1; roll <= 20; roll++) {
    printf("%d ", 1 + rand() % 6);
  }
  return 0;
}  

  unsigned r;
  srand(r); 

Fonctions Arduino

La fonction random A prend 2 arguments min et max de type long, le premier étant optionnel, tels que :

• min est une expression dont la valeur fixe la borne minimale incluse des valeurs possible du nombre aléatoire retourné par la fonction ; si cet argument n'est pas codé, la valeur par défaut est 0 ;
• max est une expression dont la valeur fixe la borne maximale exclue des valeurs possibles du nombre aléatoire retourné par la fonction.

Quant à la fonction randomSeed A, elle redéfinit simplement la fonction srand sous condition que la valeur passée en argument, de type unsigned long, soit non nulle.

Toutefois, comme la très grande majorité des cartes Arduino ne disposent pas d'un module RTC (real‑time clock) W, elles ne sont pas en mesure de délivrer une valeur de temps calendaire via la fonction time.

Aussi, pour générer une graine différente à chaque exécution d'un programme, il est d'usage d'effectuer une lecture d'une broche du port d'entrée analogique (cf. chap. C3‑VII ) de la carte dont le potentiel n'est pas référencé – c'est‑à‑dire une broche non connectée. Soumise au champ électromagnétique ambiant, une telle broche présente alors un potentiel assez faible, mais suffisant pour être non nul, et tout à fait aléatoire. Pour l'argument seed, à la place de time(NULL), on peut donc coder :
analogRead(pin)
où pin est un numéro de broche non connectée du port analogique.

const int8_t NON_CONNECTED_PIN = 0;

void setup()
{
  randomSeed(analogRead(NON_CONNECTED_PIN)); 
  Serial.begin(115200);
}  

void loop()
{
  Serial.println(random(1, 7));
  delay(1000);
}