Question sur getchar()

Version imprimable

Bonjour,

Voici un programme qui réalise la conversion d'une string minuscule en majuscule :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 #include <ctype.h> #include <stdlib.h> #include <stdio.h> #include <stdbool.h> int main(void) { while (true) { signed char c = getchar(); if (c == '\n') break; switch (c) { case 'é' : putchar('É'); break; case 'è' : putchar('È'); break; case 'ê' : putchar('Ê'); break; default: putchar(toupper(c)); break; } } putchar('\n'); return EXIT_SUCCESS; }
Lorsque je saisi un caractere sur stdin, il le compare à '\n' pour stopper la boucle s'il vaut stdin et réalise la conversion en majuscule sinon.

Je ne comprend pas pourquoi les caractères en majuscule resultant de la conversion sont affiché apres mon CR (Carrier Return). Voici un exemple d'utilisation:

Citation:

kal@kal-laptop ~ $ ./caracteres
caractères accentués
CARACTÈRES ACCENTUÉS

Bien que cela ne me dérange pas, je ne comprend pas pourquoi c'est ainsi et pas comme ça :

Citation:

cCaArRaAcCtTèÈrReEsS aAcCcCeEnNtTuUéÉsS

Merci d'avance ;)

11/07/2006, 14h32
fearyourself

C'est ce qu'on appelle la tamporisation...

Ton programme reçoit l'information du clavier lorsque l'utilisateur a appuyé sur entrée ou que le tampon est plein.

Jc
11/07/2006, 14h35
DaZumba

Remarque que getchar() renvoie un int que tu castes violemment en signed char. Ensuite, tu compares ce signed char avec des valeurs int. Declare c comme etant un int, cela permet notamment de recevoir le EOF renvoye par getchar() en cas d'erreur.
11/07/2006, 15h10
ToTo13

Bonjour,

en C, les entrées sorties sont bufferisées.
C'est justement ton retour charriot qui te permet de lancer le programme.
Sinon tu peux mettre ton texte dans un fichier.
11/07/2006, 15h31
_kal_

Merci beaucoup, j'ai compris :D

@DaZumba:
Oui j'avais pas pensé pour le int, je souhaitais juste économiser de la place. Par contre je ne savais pas que l'évaluation d'un caractère tel que 'è' retourné un int. Merci pour l'info

;)
11/07/2006, 16h54
Emmanuel Delahaye

Citation:

Envoyé par fearyourself

C'est ce qu'on appelle la tamporisation...

Euh, la quoi ? En franglais, la bufferisation (buffering), peut être ? ou la tamponisation en français...
11/07/2006, 16h55
Emmanuel Delahaye

Citation:

Envoyé par _kal_

Je ne comprend pas pourquoi les caractères en majuscule resultant de la conversion sont affiché apres mon CR (Carrier Return).

http://emmanuel-delahaye.developpez.com/notes.htm#fgetc
11/07/2006, 17h07
_kal_

Citation:

Envoyé par Emmanuel Delahaye

http://emmanuel-delahaye.developpez.com/notes.htm#fgetc

Comme d'habitude, je ne peux que saluer le travail que tu fournis. Explication très claire ;)
11/07/2006, 17h22
Emmanuel Delahaye

Citation:

Envoyé par _kal_

Comme d'habitude, je ne peux que saluer le travail que tu fournis. Explication très clair ;)

Merci. Je t'autorise de mettre un 'e' à clair...
11/07/2006, 19h50
_kal_

Citation:

Envoyé par Emmanuel Delahaye

Merci. Je t'autorise de mettre un 'e' à clair...

:aie:

Le pire, c'est que j'avais mis un 'e' à l'origine. Puis j'ai pensé que ceci designait le prénom "Claire", donc il n'y avait pas de 'e'. Mais en fait non ;)
11/07/2006, 20h10
Pragmateek
Code:

1 2 3 default: putchar(toupper(c)); break;
Le "break" pour le "default case" est facultatif.

Citation:

Envoyé par seriousme

Code:

1
2
3
default:
putchar(toupper(c));
break;

Le "break" pour le "default case" est facultatif.

Rien à voir avec default. Le dernier break est facultatif :

Code:

1
2
3
4
5
6
7
8
9
10
 
        switch (c)
        {
          case 'é' :
            putchar('É');
            break;
 
          default:
            putchar(toupper(c));
        }

Code:

1
2
3
4
5
6
7
8
9
10
 
        switch (c)
        {
          default:
            putchar(toupper(c));
            break;
 
          case 'é' :
            putchar('É');
        }

etc.

11/07/2006, 20h18
Pragmateek

Citation:

Rien à voir avec default. Le dernier break est facultatif :

Exact mais souvent il y a un "default case" même si il est vide.
11/07/2006, 20h49
_kal_

En effet, je n'ai fait que recopier l'exemple du livre que je lit actuellement (Méthodologie de programmation en C99 - API POSIX).
11/07/2006, 22h21
Jean-Marc.Bourguet

Quelques remarques:
- on ne passe pas un char, surtout signed, à toupper sans le transformer en unsigned char
- si le résultat de getchar est un int, ce n'est pas pour rien; c'est pour pouvoir traiter la fin des fichiers
- si on veut que toupper fonctionne avec les caractères hors du jeu de base, il faut utiliser les locales
11/07/2006, 22h53
_kal_
Citation:

Envoyé par Jean-Marc.Bourguet

- on ne passe pas un char, surtout signed, à toupper sans le transformer en unsigned char

Méthodologie de la programmation en C - Norme C99 - API POSIX (Page 121) :
Citation:
Si l'on change en <unsigned char c = getchar(); > la déclaration de la variable c, on obtient le résultat suivant :

Code:

1 2 3 $ caracteres caractères accentués CARACTèRES ACCENTUéS

La raison de ce dysfonctionnement apparent est simple. Prenons le cas du caractère 'é', codé dans la norme ISO par la suite de bits 11101001. Sur un octet, cette valeur code la valeur décimale 233 dans le cas d'une arithmétique sans signe, et -23 dans le cas d'une arithmétique signée. Une constante caractère étant de type int, elle est signée. La valeur de la constante 'é' est -23. Par contre la variable c étant de type unsigned char, sa valeur est 233.
La première version du programme n'est par conséquent pas portable car elle dépend de l'implémentation du type char. Pour y remédier, il faut déclarer la variable c de type signed char. Nous verrons d'autre part, dans le chapitre 6, qu'il existe un mécanisme portable appelé contrôle local, permettant de prendre en compte les spécificités des différentes langues.
C'est pourquoi la variable c est déclaré en signed char. Par ailleurs, je ne comprend pas pourquoi il ne faut pas passer de char, surtout signed, à la fonction toupper. En effet, il y aura une promotion intégral lors de l'appel toupper(c) qui réalisera une conversion implicite de signed char vers int. Est ce due au fait qu'il y a une extension du bit de signe? Pourtant ce programme semble marcher...

Citation:

Envoyé par Jean-Marc.Bourguet

- si le résultat de getchar est un int, ce n'est pas pour rien; c'est pour pouvoir traiter la fin des fichiers

Exact, mais l'auteur ne le précise pas dans l'ouvrage (du moins pas encore). Mais c'est vrai qu'il faut un int pour traiter EOF.

Citation:

Envoyé par Jean-Marc.Bourguet

- si on veut que toupper fonctionne avec les caractères hors du jeu de base, il faut utiliser les locales

Là par contre, mon niveau de connaissance n'atteint pas encore ce stade. Bientôt si tout va bien ;)

Merci en tout cas pour ces remarques constructives.
11/07/2006, 22h59
Médinoc

Au fait : Pour ceux qui veulent jouer avec l'unicode, et les wchar_t, Je ne crois pas qu'il y ait problème de ce coté : wchar_t est supposé non-signé. À moins qu'il ne faille utiliser wint_t ?
Edit: wchar_t n'est donc pas forcément non-signé, mais on peut passer directement un wchar_t aux fonctions de <wctype.h>.

Et pour ceux qui tournent sous Windows et souhaitent compiler dans les deux modes (ils utilisent donc les TCHAR), ils ne peuvent convertir directement en unsigned char ou en int. Heureusement, le type _TUCHAR (déclaré dans tchar.h) est fait pour cela.
12/07/2006, 08h53
Jean-Marc.Bourguet

Citation:

Envoyé par _kal_

Méthodologie de la programmation en C - Norme C99 - API POSIX (Page 121) :

J'ai pas lu ce bouquin, mais les explications que tu cites sont vaseuses...

Citation:

C'est pourquoi la variable c est déclaré en signed char. Par ailleurs, je ne comprend pas pourquoi il ne faut pas passer de char, surtout signed, à la fonction toupper.

Parce que la norme demande que les int passes aux fonctions de ctype.h soient soit EOF, soit des unsigned char converti en int.

Si tu utilises un int, il y a deux problemes: tout d'abord tu ne peux pas faire la distinction entre 'ÿ' et EOF si tes char sont signes, ensuite tu risques de passer d'autres valeurs negatives auxquelles toupper ne s'attend pas. Une implementation classique etant d'indexer un tableau, tu peux lire n'importe quoi ou meme arreter brutalement ton programme.
12/07/2006, 10h25
_kal_

Citation:

Envoyé par Jean-Marc.Bourguet

Si tu utilises un int, il y a deux problemes: tout d'abord tu ne peux pas faire la distinction entre 'ÿ' et EOF si tes char sont signes, ensuite tu risques de passer d'autres valeurs negatives auxquelles toupper ne s'attend pas. Une implementation classique etant d'indexer un tableau, tu peux lire n'importe quoi ou meme arreter brutalement ton programme.

Ok, merci j'ai compris :)
12/07/2006, 10h41
Jean-Marc.Bourguet

Citation:

Envoyé par Médinoc

wchar_t est supposé non-signé

Pas a ma connaissance.

Citation:

À moins qu'il ne faille utiliser wint_t ?

Pas non plus garanti non signe a ma connaissance.
12/07/2006, 10h43
Médinoc

Mince.
Mais est-ce qu'un compilateur accepte qu'on entre "unsigned wchar_t" ?
Surtout lorsque wchar_t n'est pas un type natif ? (sur les vieux compilateurs)
12/07/2006, 10h50
Jean-Marc.Bourguet

Citation:

Envoyé par Médinoc

Mais est-ce qu'un compilateur accepte qu'on entre "unsigned wchar_t" ?
Surtout lorsque wchar_t n'est pas un type natif ? (sur les vieux compilateurs)

En C, wchar_t est un typedef defini dans stddef.h. Donc qualifier avec unsigned n'est pas possible.

En C++ wchar_t est bien un type, mais tu ne peux pas non plus le qualifier avec unsigned.
12/07/2006, 10h51
Médinoc

Le vieux GCC du vieux FreeBSD de mon école n'aime pas (syntax error before 'nom_de_la_variable_unsigned_wchar_t')
Le GCC 3.4.5 de la redhat de mon école n'aime pas non plus...

Alors comment je fais pour utiliser iswalpha() qui demande un wint_t ?
12/07/2006, 10h56
Jean-Marc.Bourguet

Citation:

Envoyé par Médinoc

Le vieux GCC du vieux FreeBSD de mon école n'aime pas (syntax error before 'nom_de_la_variable_unsigned_wchar_t')
Le GCC 3.4.5 de la redhat de mon école n'aime pas non plus...

Alors comment je fais pour utiliser iswalpha() qui demande un wint_t ?

Tu passes ton wchar_t. Quel est le probleme? Qu'il y a un piege en moins que pour les char?
12/07/2006, 11h03
Médinoc

Le problème, c'est que j'ai cru à la lecture de ton post 20 qu'il n'y avait justement pas "un piège en moins" contrairement à ce que je croyais avant...