Ce que fscanf renvoie, et ce qu'il coûte de l'ignorer

/* (A) */  while (!feof(f)) { fscanf(f, "%d", &x); somme = somme + x; }

/* (B) */  while (fscanf(f, "%d", &x) == 1) { somme = somme + x; }

(B) est correcte : elle lit $12$ puis $7$, échoue sur abc, et s'arrête. Mesure : somme $=19$ après $2$ tours.

(A) est une boucle infinie, et la mesure le montre : bridée à douze tours, elle donne $89=12+7\times 11$. Voici pourquoi, et il y a deux fautes indépendantes.

Première faute : fscanf peut échouer sans consommer. Devant abc, la conversion %d échoue ; fscanf rend $0$ et laisse les caractères dans le flux. On les retrouvera au tour suivant, à l'identique, indéfiniment.

Seconde faute : x n'est pas modifié en cas d'échec. La boucle ajoute donc onze fois la dernière valeur lue, $7$. Ce n'est même pas de la mémoire indéterminée — c'est une vieille valeur, parfaitement plausible, ce qui rend le résultat d'autant plus difficile à mettre en doute.

Troisième piège, celui du nom : feof ne prédit pas la fin, il constate qu'une lecture a déjà buté dessus. Tant qu'aucune lecture n'a atteint la fin du fichier, feof rend faux — et ici aucune ne l'atteindra jamais, puisqu'on est bloqué sur abc.

La règle, et elle vaut pour toute la famille : une fonction de lecture rend le nombre de conversions réussies, et c'est cette valeur — pas feof — qui pilote la boucle. On écrit == 1 et non != EOF : fscanf rend $0$ sur une donnée malformée et EOF seulement en fin de fichier, et l'on veut s'arrêter dans les deux cas.