Problème avec getchar().. (exo K&R)

Version imprimable

19/07/2012, 23h46
hidelov_U

Problème avec getchar().. (exo K&R)
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:

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.
20/07/2012, 01h13
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().
20/07/2012, 12h29
hidelov_U

Merci pour cette réponse très complète ;)
31/07/2012, 18h15
fantomas261

bonjour
je voudrais savoir pour la valeur de la constante EOF s'écrit avec des parenthèses ?
merci
31/07/2012, 18h44
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.
13/08/2012, 19h15
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
13/08/2012, 19h24
Jean-Marc.Bourguet

- EOF est antérieur à const.
- en C l'utilisation de variables const n'est pas permise dans les expressions constantes (le plus génant dans le cas de EOF doit être après un case; en passant en C++ c'est autorisé)
14/08/2012, 22h45
fantomas261

et pourquoi on a :
#define EOF (-1) et non #define EOF -1 ?
14/08/2012, 23h01
Jean-Marc.Bourguet

Citation:

Envoyé par fantomas261

et pourquoi on a :
#define EOF (-1) et non #define EOF -1 ?

Beaucoup ont l'habitude de mettre systématiquement des parenthèses autour d'une expression dans une macro et autour de chaque argument. Sans cette précaution, il est facile d'écrire des macros qui vont être évaluées différemment suivant le contexte. Dans le cas présent, je ne vois pas directement de contexte où le problème pourrait se produire, ce qui ne garanti pas que la précaution est inutile.
16/08/2012, 10h43
ternel

parce que si un gugus écrit -EOF, ca donne bien -(-1), donc 1, qui compile, plutot que --1, qui ne compile pas.
16/08/2012, 15h50
Jean-Marc.Bourguet

Citation:

Envoyé par leternel

parce que si un gugus écrit -EOF, ca donne bien -(-1), donc 1, qui compile, plutot que --1, qui ne compile pas.

Les macros sont définies sur les symbles, -EOF donnerait trois symboles, - - 1, si EOF était définit comme -1.

(Le simple fait que ça évite de se poser des questions est pour moi une raison suffisante d'être systématique sur les parenthèses quand on écrit des macros.).
16/08/2012, 16h12
Obsidian
Citation:

Envoyé par Jean-Marc.Bourguet

Les macros sont définies sur les symbles, -EOF donnerait trois symboles, - - 1, si EOF était définit comme -1.

Euh, es-tu sûr de cela ?

Citation:

Envoyé par leternel

parce que si un gugus écrit -EOF, ca donne bien -(-1), donc 1, qui compile, plutot que --1, qui ne compile pas.

Chez moi, ça compile (avec GCC 4.6.3). Le code suivant :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 #include <stdio.h> #undef EOF #define EOF -1 int main (void) { printf ("%d\n",EOF); printf ("%d\n",-EOF); printf ("%d\n",EOF EOF); return 0; }
… une fois traduit avec « gcc -E », donne :
Code:

1 2 3 4 5 6 7 8 int main (void) { printf ("%d\n",-1); printf ("%d\n",- -1); printf ("%d\n",-1 -1); return 0; }
Donc, à la deuxième ligne, un espace a été explicitement inséré, tandis que les autres sont restés en l'état. Et ce même en C89. Je n'ai pas réussi à trouver le passage de la norme qui traite de cela, donc je ne sais pas si c'est quand même défini dedans ou si c'est GCC qui comble un « comportement indéterminé ».
16/08/2012, 16h27
Jean-Marc.Bourguet

Citation:

Envoyé par Obsidian

Euh, es-tu sûr de cela ?

Citation:

Envoyé par C90

A preprocessing directive of the form

Code:

# define identifier replacement-list new-line

defines an object-like macro that causes each subsequent instance of the macro name to be replaced by the replacement list of preprocessing tokens that constitute the remainder of the directive.

De plus, l'existence de ## montre bien que le remplacement n'est pas du pur texte destiné à être rescanné.
16/08/2012, 17h22
Obsidian

Ça d'accord, c'est la définition des macros telles qu'on les connaît dans leur forme la plus courante, et ça signifie exactement :

Citation:

Une directive de pré-traitement de la forme :

Code:

# define identifiant liste-de-remplacement retour-à-la-ligne

… définit une macro semblable à un objet provoquant le remplacement de toutes les instances suivantes du nom de la macro par la liste de remplacement de lexons qui constituent le reste de la directive.

… mais je ne vois toujours pas pourquoi un « -1 » devrait être décomposé en deux symboles distincts s'il ne l'est pas à la base.
16/08/2012, 17h33
Jean-Marc.Bourguet

À la base, -1 c'est deux lexèmes, pas un seul.
17/08/2012, 09h31
ternel

Citation:

Envoyé par Jean-Marc.Bourguet

Les macros sont définies sur les symbles, -EOF donnerait trois symboles, - - 1, si EOF était définit comme -1.

(Le simple fait que ça évite de se poser des questions est pour moi une raison suffisante d'être systématique sur les parenthèses quand on écrit des macros.).

J'avais eu une expérience différente, mais avec un autre compilateur (je ne sais d'ailleurs plus lequel)
17/08/2012, 15h55
fantomas261

Code:

printf("%d", -EOF*2);

j'obtiens 2 à l’exécution

Code:

printf("%d", - - 1);

1 à l exécution
17/08/2012, 19h54
Obsidian

Citation:

Envoyé par fantomas261

Code:

printf("%d", -EOF*2);

j'obtiens 2 à l’exécution

Code:

printf("%d", - - 1);

1 à l exécution

Il faut regarder la grammaire du langage ainsi que le chapitre 5 de la norme, § 5.1.1.2 « Translation phases » :

Le flux est découpé en « preprocessing tokens », puis les macros sont développées, et le résultat est enfin ré-analysé pour former les tokens définitifs qui, eux, vont pouvoir être compilés. Par ailleurs, à la section 6.4, on lit :

Citation:

6.4 Lexical elements
Syntax
1
token:
keyword
identifier
constant
string-literal
punctuator

preprocessing-token:
header-name
identifier
pp-number
character-constant
string-literal
punctuator
each non-white-space character that cannot be one of the above

Ce qui veux dire que les preprocessing tokens sont capables de reconnaître dès le départ les identifiants (soit les symboles qui ne commencent pas par un chiffre, par exemple les noms de variables), les nombres et quelques autres choses. Et tout ce qui ne rentre pas dans ces cas de figure est considéré comme « un mot » qui tombe donc automatiquement dans le dernier.

Par contre, la grammaire des pp-numbers ne tient pas compte du signe, qui sera donc interprété comme un lexème distinct. Toujours est-il qu'au moment de passer à la phase suivante, le compilateur sait déjà que EOF est en fait « - » (punctuator) + « 1 » (pp-number). Donc, le fait d'avoir découpé ça en pré-tokens d'un certain nombre de catégories permet justement de gérer les cas particulier quand il y a lieu de le faire et de revenir à un développement classique pour tous les autres.