Cent pour cent des instructions, quatre-vingt-trois pour cent des arcs

int classe(int x) {
    int r;
    if (x < 0) { r = -1; }
    else if (x == 0) { r = 0; }
    else { r = 1; }
    return r;
}
int f(int x) {
    int y = 0;
    if (x > 0) { y = 1; }      /* pas de else */
    return 10 / y;
}

La mesure, avec gcc –coverage puis llvm-cov gcov -b :

Lines executed:       100.00% of 13
Taken at least once:   83.33% of 6

    1:   11:    if (x > 0) { y = 1; }      /* pas de else */
branch  0 taken 100%
branch  1 taken   0%          <-- l'arc jamais emprunte

Toutes les instructions sont exécutées, et un arc sur six ne l'est pas : celui qui saute le corps du if, c'est-à-dire exactement celui qui laisse $y$ à zéro. Le chiffre $83,33\%=5/6$ n'est pas une approximation : l'outil compte six arcs, et cinq ont été pris.

Ajouter f(-1) au jeu de tests porte les deux mesures à $100\%$.

Et l'exécution ? C'est ici que l'exercice devient inquiétant. Le même programme, sur la même entrée, avec deux niveaux d'optimisation :

gcc -O0 : f(-1) = 0    code de sortie 0
gcc -O2 : f(-1) = 10   code de sortie 0

Deux réponses différentes, et aucun plantage. La division entière par zéro est un comportement indéfini en C : le langage n'exige rien du tout, et deux compilations du même texte peuvent légitimement diverger.

• À -O0 sur ce processeur, l'instruction de division rend $0$ sans lever d'exception matérielle.
• À -O2, l'optimiseur raisonne : « 10 / y est évaluée, donc $y\ne 0$, donc le if a été pris, donc $y=1$, donc le résultat est $10$ ». Il élimine la branche et écrit la constante.

Sur d'autres machines, le même programme s'arrête brutalement sur un signal.