Une assertion qui change le programme

int appels = 0;
int suivant(void) { appels = appels + 1; return appels; }

int main(void) {
    assert(suivant() > 0);
    printf("appels = %d\n", appels);
    printf("suivant() = %d\n", suivant());
    return 0;
}

gcc -Wall -Wextra -std=c99            : appels = 1   suivant() = 2
gcc -Wall -Wextra -std=c99 -DNDEBUG   : appels = 0   suivant() = 1

Ce qui se passe. assert est une macro, et la définition standard la réduit à rien quand NDEBUG est défini. Ce n'est pas seulement le test qui disparaît : c'est toute l'expression, avec ses effets. Ici, l'appel à suivant() n'a jamais lieu, et le compteur reste à zéro.

La règle : une assertion ne doit contenir aucun effet de bord. Pas d'appel qui modifie un état, pas d'affectation, pas d'incrémentation, pas de lecture sur un flux. On écrit :

int v = suivant();      /* l'effet a lieu, toujours */
assert(v > 0);          /* la verification, elle, peut disparaitre */

Et le corollaire, plus important encore. Une assertion vérifie une propriété ; elle ne réalise rien. Sur le même programme :

int racine_entiere(int n) { assert(n >= 0); ... }

sans NDEBUG : Assertion failed: (n >= 0), function racine_entiere,
              file afail.c, line 3.        code de sortie 134
avec NDEBUG : 0                            code de sortie 0

La version livrée ne signale plus rien et rend $0$ pour $\sqrt{-4}$. C'est cohérent avec ce qu'une assertion est — un filet pour le développement, qui suppose la précondition tenue — et c'est incompatible avec l'idée de s'en servir pour valider une entrée. Une donnée qui vient de l'extérieur se teste par un if, qui, lui, ne disparaît jamais.