Discussion :

[hidelov_U]

Bonsoir,

J'ai un soucis avec un exo du K&R qui consiste a compter tout bêtement le nombre de caractères saisis par l'utilisateur à l'aide d'un getchar(). En fait le retour chariot est compté après chaque saisie, ce qui fausse donc la donne. Du coup si j'entre 3 caractère (1 par ligne), le résultat final (nc) sera 6 et non 3 !

Je vous montre le code :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
#include <stdio.h>
 
main()
{
  // Compte les caractères en entrée
 
  long nc;
 
  nc = 0;
  while (getchar() != EOF)
    ++nc;
 
  printf("%ld caractères(s)\n", nc);
}

C'est normal ou pas ?

Merci.

[Obsidian]

Bonjour,

Oui, c'est tout-à-fait normal : le retour à la ligne et le saut de ligne font partie des caractères de contrôle du code ASCII. Étant donné qu'à l'époque, on travaillait avec des terminaux passifs et que ceux-ci était reliés à l'unité centrale via une ligne série, il était nécessaire que ces « caractères de contrôle » fassent partie de cette table puisque c'est la seule chose que l'on pouvait envoyer et que c'était donc le seul moyen de piloter le terminal. C'est d'ailleurs la raison d'être de la touche « Ctrl » qui permet de les exprimer, même si peu de gens le savent encore aujourd'hui.

À noter que tous les systèmes ne codent pas le retour à la ligne de la même façon. Unix n'utilise que le saut de ligne (tabulation verticale, code 10 ou 0x0a) pour signifier une nouvelle ligne (d'où « \n ») mais D.O.S. et Windows utilisent explicitement deux caractères par saut : « \r » puis « \n », respectivement 13 et 10, et qui servent à revenir en début de ligne (retour chariot) puis à sauter une ligne (tabulation verticale), ce qui était effectivement le mouvement effectué sur les machines à écrire.

Ça tient debout, mais ces disparités entre systèmes restent assez ennuyeuses à gérer au quotidien. De toutes façons, la tendance est aujourd'hui à l'UTF-8 qui, par nature, peut utiliser de un à quatre codes successifs pour représenter un même caractère. On ne peut plus faire l'amalgame « 1 code = 1 caractère » et du coup, la différence entre DOS et Unix sur les retours à la ligne devient moins génante.

À noter enfin qu'EOF n'est pas un caractère d'ASCII mais un marqueur extérieur à cette table. Il sert à indiquer que la lecture du flux a atteint sa fin pour une raison quelconque : soit c'est vraiment la fin du fichier (EOF = End Of File), soit c'est un tube refermé par l'écrivain (typiquement le cas quand on saisit des touches au clavier), soit une erreur s'est produite, indiquée le cas échéant par ferror().

[hidelov_U]

Merci pour cette réponse très complète

[fantomas261]

bonjour
je voudrais savoir pour la valeur de la constante EOF s'écrit avec des parenthèses ?
merci

[Obsidian]

Non, EOF est une macro #define (qui vaut généralement « -1 » mais on n'est pas censé le savoir).

C'est pour cette raison que fgetc() et d'autres fonctions renvoient un « int » et pas un « char » : elles renvoient un type entier un peu plus grand qui puissent coder toutes les valeurs d'un char plus certaines autres pour que l'on puisse clairement faire le distingo entre les deux.

[fantomas261]

Pourquoi ceux qui ont crées la langage C ont définit EOF comme une macro et non une constante ?
Quel est l’intérêt de définir une macro sans paramètre ?
merci