Jeu du plus ou moins

Version imprimable

30/06/2014, 14h36
Tom Dar

1 pièce(s) jointe(s)

Jeu du plus ou moins

Bonjour à tous, chers développeurs.

Depuis 2 jours, j'ai commencé à apprendre en autodidacte le langage C.
Néanmoins, il y a un petit problème lors de la programmation d'un jeu nommé "Plus ou moins". :oops:

Je vous met en photo le code qui convient à ce jeu avec le problème que je ne comprend pas. :?

Pièce jointe 150021

Pouvez-Vous m'aider à résoudre ce problème ce problème s'il vous plaît ?
J'ai essayé de le résoudre en mettant un ';' à la ligne 24 comme ceci : else (Nombre_Entre == Nombre_Mystere);
Le programme fonctionne mais ça me met n'importe quoi.

Je vous remercie d'avance ! :zoubi:
30/06/2014, 14h43
Bovino

J'ai jamais fait de C de ma vie, mais mettre une expression dans un else me semble toutefois assez loufoque. :mrgreen:
30/06/2014, 14h47
Tom Dar

Oui en effet, le programme fonctionne merci :mrgreen:
J'y ferais gaffe la prochaine fois !
30/06/2014, 15h12
fregolo52

Salut,

pour les prochaines fois, pense à copier ton code avec la base [code] (# dans la barre d'outils) plutôt que de poster une image. C'est moins lourd et quand on répond on peut réutiliser ton code. ;)
30/06/2014, 15h17
ternel

Tant que tu y es, puisque tu découvre le langage, fais un tour par notre FAQ.
Elle est très intéressante, car, pour l'essentiel, elle explique pourquoi faire ou ne pas faire certaines choses.

Je te dis ca autant pour la pub que comme avertissement.

Lire la FAQ C t'aidera à avoir un esprit critique vis-à-vis de ce que tu apprends.
30/06/2014, 15h36
Tom Dar

Merci à tous pour vos conseils précieux :D
Je vais aller faire un tour à la FAQ C et les cours C de ce pas !
30/06/2014, 17h03
Sve@r

Bonjour

Citation:

Envoyé par Bovino

J'ai jamais fait de C de ma vie, mais mettre une expression dans un else me semble toutefois assez loufoque. :mrgreen:

Sisi, c'est autorisé. Après else t'as le droit de mettre une instruction. Et "if (...)" est bien une instruction (ceci dit, t'as quand-même "elif" qui est justement fait pour alléger cette syntaxe). C'est toutefois peu recommandé car t'as le droit de n'en mettre qu'une seule (s'il y en a plusieurs il faut alors les encadrer avec des accolades). Or le if (...) et tout son bloc then/else est compris comme ne faisant qu'une seule instruction. Ce qui donne un code effectivement un peu obscur (il faut alors se rappeler de tous ces détails pour comprendre comment se comporte le code quoi...)
30/06/2014, 17h15
Bovino

Je ne crois pas qu'on parle de la même chose...

Je faisais allusion à la ligne 24 de Tom Dar :

Code:

else (Nombre_entre == Nombre_mystere)

et non à la ligne 25 qui correspond effectivement à une instruction. ;)

1 pièce(s) jointe(s)

J'ai de nouveau un problème dans un autre code. Je profite de ce topic au lieu d'en créer un autre ça sera d'autant plus simple.

Voici mon code :

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
38
39
40
41
42
43
44
45
46
47
48
49
50
#include <stdio.h>
#include <stdlib.h>
 
double conversion (double euros)
{
    return euros * 0.8003;
}
 
double conversionInv (double livres)
{
    return livres * 1.2496;
}
 
int main()
{
        int mode = 1;
printf ("1 = Conversion de l'euro au livre\n");
printf ("2 = Conversion du livre a l'euro\n");
scanf ("%d", &mode);
 
    if (mode == 1)
    {
    double NombreEntre = 0, NombreConvert = 0;
 
 printf ("Entrez une somme en euro :  ");
 scanf("%d", &NombreEntre);
 
 NombreConvert = conversion(NombreEntre);
 
 printf ("La somme est de %d livres sterling\n\n", NombreConvert);
}
 
    else if (mode == 2)
    {
            double NombreEntre = 0, NombreConvert = 0;
 
 printf ("Entrez une somme en livre sterling :  ");
 scanf("%d", &NombreEntre);
 
 NombreConvert = conversionInv(NombreEntre);
 
 printf ("La somme est de %d euros\n\n", NombreConvert);
    }
 
    else
    {
        printf ("Veuillez entrer un chiffre valable ! \n\n");
    }
    return 0;
}

Mais seulement voici ce que me met le logiciel comme message :

Pièce jointe 150054

Cela vient d'une erreur dans mon code ?

Merci encore de l'aide :roll:

30/06/2014, 20h30
Bktero

Citation:

Envoyé par Bovino

Je ne crois pas qu'on parle de la même chose...

Je faisais allusion à la ligne 24 de Tom Dar :

Code:

else (Nombre_entre == Nombre_mystere)

et non à la ligne 25 qui correspond effectivement à une instruction. ;)

Le connaissant je crois qu'il va chipoter en disant que c'est un test et non une instruction. :)

Citation:

J'ai de nouveau un problème dans un autre code.

%d est pour lire un int et non un double. Ça ne parait pas logique je sais. Il faut utiliser %f.
30/06/2014, 21h02
Bovino

Ben moi aussi je vais chipoter, mais je n'ai pas parlé d'instruction :

Citation:

Envoyé par Bovino

mettre une expression dans un else

Citation:

et non à la ligne 25 qui correspond effectivement à une instruction

ici, je parle bien d'instruction, mais précisément pour la ligne suivante qui ne correspond pas à l'erreur.
:mrgreen:
30/06/2014, 21h05
Tom Dar

Citation:

Envoyé par Bktero

%d est pour lire un int et non un double. Ça ne parait pas logique je sais. Il faut utiliser %f.

En remplaçant, les %d nécessaire par %f, le problème est toujours le même. Mais en effet c'est plus logique.
30/06/2014, 21h30
Sve@r

Citation:

Envoyé par Bktero

Le connaissant je crois qu'il va chipoter en disant que c'est un test et non une instruction. :)

Nan, pas ici surtout qu'effectivement je pensais qu'il parlait de la ligne 25.
Et puis même une évaluation reste tout de même une instruction => int i=(x == y) :P

Citation:

Envoyé par Tom Dar

En remplaçant, les %d nécessaire par %f, le problème est toujours le même.

T'es sûr ? Le même message d'erreur concernant la même ligne ???
30/06/2014, 22h13
Tom Dar

Oui le même message sur la même ligne.
01/07/2014, 09h36
Sve@r
Citation:

Envoyé par Tom Dar

Citation:

Envoyé par Bktero

Il faut utiliser %f.

Oui le même message sur la même ligne.

Ahah, Bktero t'a introduit en erreur :P
En fait, %f pour un double est accepté au printf parce que printf sait faire la différence entre un float et un double (grace au codage interne de la valeur à afficher)

Mais scanf(), lui, ne sait pas faire pour la bonne raison qu'il n'a pas de valeur lui. Lui, il a juste une variable qui sera remplie avec la valeur saisie. Et donc, scanf doit impérativement recevoir le format exact du nombre à saisir. %f c'est pour les float, pour les doubles c'est %lf.
Bien sûr, celui qui se force à être rigoureux dans les formats du printf sera avantagé quand il devra faire du scanf
- %c => char
- %d => int signé
- %u => int non signé
- %hd => short signé
- %hu => short non signé
- %ld => long signé
- %lu => long non signé
- %f => float
- %lf => double
- %Lf => long double (si implémenté)
- %s => string (pointeur vers une zone de caractères contenant impérativement un '\0' quelque part)
Ceci dit, à sa décharge, c'est pas évident de se souvenir immédiatement de ce détail. Même moi d'ailleurs j'ai lu son message sans tiquer. C'est suite à ton insistance que j'ai recopié ton code pour ensuite me souvenir de ça...
01/07/2014, 11h25
Tom Dar

J'ai donc remplacé tous les %f par les %lf et cela fonctionne parfaitement. :D
Je vais garder votre message précieusement Sve@r, ça pourra toujours servir !

+/-

Bonjour
j'aimerais savoir qu'arrive-t-il si dans ton jeu plus ou moins je saisis une lettre ?
je ne suis pas expert en langage C mais serait-t-il pas préférable de faire un contrôle de saisie avant de valider le choix ?

Exemple

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
 
/**
* Fonction Saisie de nombre 
* et gestion automatique du buffer
**/
int f_GetSaisie(void){
 
	int _ret = 0;
	int _saisie = 0;
	int _nombre = 0;
 
	while(!_saisie){
 
		_ret = scanf("%d%*[^\n]",&_nombre);
		if(!_ret){
 
			int _tmp = 0;
			while( ((_tmp = getchar())!='\n') && (_tmp != EOF) );
			printf("\n[Recommencez] Veuillez Entrer que des nombres\n");
		}
		_saisie = 1;
	}
	return (_nombre);
}

Ce qui donnerait un code du genre ci-dessous et s'il y a des experts qui peuvent porter attention sur le code et me dire s'il est correcte,
bref tout avis est la bienvenue à bientôt.

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
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
 
/**
*       @Author : Sambia39
*       @Licence: GPL v3
*       @Mail   : <a href="mailto:admin@xjagercodes.com">admin@xjagercodes.com</a>
*       @Web    : <a href="http://www.xjagercodes.com" target="_blank">www.xjagercodes.com</a>
**/
 
#include <time.h>
#include <stdio.h>
#include <stdlib.h>
 
/**
*       Définition du clear 
*       selon le système
**/
 
#if defined(WIN32) && !defined(UNIX)
	#define clear system("cls")
#elif defined(UNIX) && !defined(WIN32)
	#define clear printf("\033[2J")
#else
	#define clear printf("\033[2J")
#endif
 
 
/**
*       Fonction de générateur 
*       de nombre speudo aléatoire
**/
int f_Rand(const int arg){
 
	static int _seed = 0;
	if(!_seed){
		_seed = 1;
		srand(time(NULL));
	}
	return ( rand() % arg);
}
 
 
/**
* Fonction Saisie de nombre 
* et gestion automatique du buffer
**/
int f_GetSaisie(void){
 
	int _ret = 0;
	int _saisie = 0;
	int _nombre = 0;
 
	while(!_saisie){
 
		_ret = scanf("%d%*[^\n]",&_nombre);
		if(!_ret){
 
			int _tmp = 0;
			while( ((_tmp = getchar())!='\n') && (_tmp != EOF) );
			printf("\n[Recommencez] Veuillez Entrer que des nombres\n");
		}
		_saisie = 1;
	}
	return (_nombre);
}
 
/**
*       Teste de nombre
*       mistère trouver
***/
int f_GetWin(int iArg, int const iWin){
 
	clear;
	if(iArg < iWin){
		printf(" C'est plus !\n");
		return (0);
	}
	else if( iArg > iWin){
		printf(" C'est Mouins !\n");
		return (0);
	}
	else
		return (1);
}
 
/**
*       Fonction & menu du jeux
**/
int f_Menu(void){
 
	int ret = 0;
	int nombre = 0;
 
	do{
		clear;
		printf( "\t===\tPlus Ou Moins\t===\t\n\n");
		printf("\t\t 1 -> Jouer\n");
		printf("\t\t 2 -> Quitter\n");
 
		while(!nombre)
			nombre = f_GetSaisie();
		ret = 1;
 
	}while(!ret);
 
	return (nombre);
}
 
void f_StartGame(void){
 
	clear;
	int Win = 0;
	int loop = 0;
	int ret = f_Menu();
	if( !(ret = f_Config(ret)) )
		ret = 0;
 
	else{
		while(!Win){
			loop = 0;
			while(!loop){
				loop = f_Saisie_Joueur();
			}
 
			Win = f_GetWin(loop,ret);
		}
 
		clear;
		getchar();
		printf("Barvo ! vous avez trouvez le nombre mystere\t %d\a\n",ret);
		printf("Appuyer sur une touche pour revenir au menu ...\n");
		if( getchar() )
			f_StartGame();
	}
}
 
/**
*       Configuration des bornes
*/ 
int f_Config(int const in){
 
	int ret = 0;
	int borne = 0;
 
	switch(in){
		case 1:
			clear;
			printf("Entrer les bornes du nombre mystere\n");
			printf("Exemple\t: 100 donc (0-99)\n");
			while(!borne){
 
				if( (borne = f_GetSaisie()) && (borne <= 5) ){
					printf("la borne doit etre superieur a (5)\n");
					borne = 0;
				}
			}
 
			ret = f_Rand(borne);
			clear;
			break;
 
		case 2:
			clear;
			printf("Aurevoir\n");
			ret = 0;
			break;
 
		default:	
			//Aucun cas definie
			break;
	}
 
	return (ret);
}
 
 
/**
*       Boucle saisie joeur     
**/
int f_Saisie_Joueur(void){
 
	int ret = 0;
 
	while (!ret){
		printf("Quel est le nombre mystère ? \n");
		ret = f_GetSaisie();
	}
	return (ret);
}
 
 
/**
*       Fonction principale
**/
int main(void){
 
	f_StartGame();
	return (0);
}

Citation:

Envoyé par sambia39

j'aimerais savoir qu'arrive-t-il si dans ton jeu plus ou moins je saisis une lettre ?
je ne suis pas expert en langage C mais serait-t-il pas préférable de faire un contrôle de saisie avant de valider le choix ?

Dans l'absolu tu as tout à fait raison. Mais rien ne vaut le plaisir de voir son premier programme fonctionner et tant pis si tout n'est pas parfait.

Par ailleurs, et ceci est un vrai problème, scanf() n'est pas adapté à la saisie humaine. Parce que scanf() attend une saisie formattée et ce que tape un humain est tout sauf formatté.

Et même si l'utilisateur y met la meilleure volonté du monde, scanf() pose des soucis. Ne serait-ce que parce que l'utilisateur, quand il entre sa saisie, la valide par "return" et le return, n'étant pas du nombre, reste stocké dans le buffer clavier (stdin) et ira pourrir la saisie suivante. Et que se passe-t-il, si l'utilisateur entre 50 caractères dans une string prévue pour 10 ? Ca scanf ne sait pas trop le gérer (je crois qu'on peut mettre des limiteurs dans %s mais j'ai pas trop l'habitude).
Malheureusement un apprenti a rapidement besoin de saisie pour ses TP et scanf est une des méthodes de saisies des plus simples à expliquer (ne serait-ce que par son analogie avec printf) et c'est pourquoi beaucoup de cours/tutos y arrivent très (trop) vite.

Donc celui qui veut faire son petit code rapide utilisera scanf. Mais celui qui veut faire un vrai code un petit peu protégé, devra abandonner cette fonction pour en trouver une autre.

Le vrai problème est cette histoire de buffer clavier qui reste pollué. Généralement la majorité de profs (qui n'ont jamais vaiment fait du C de façon professionnelle) donnent la solution fflush(stdin) à placer avant un scanf et sensée nettoyer le clavier. Malheureusement la fonction fflush() n'est pas prévue pour un buffer input et peut très bien ne pas implémenter ce cas. Ou l'implémenter mal. Et de toute façon la norme de fflush précise que cette fonction est prévue pour des flux sortants et non entrants.

Donc la bonne solution est de considérer toute la saisie comme du texte et passer par une fonction dédiée à récupérer du texte => fgets() qui possède en plus l'avantage de pouvoir limiter le nb de caractères saisis. Ainsi, on se protège contre une saisie trop large et en plus le <return> résiduel étant du texte sera lui-aussi récupéré et libèrera le buffer clavier qui reste alors toujours clean.
Et une fois le texte récupéré, rien n'interdit de l'analyser pour en extraire les infos demandées. Ce qui, en plus, permet de détecter si l'info y était ou pas. Et ça, sscanf() (scanf depuis une string) sait très bien le faire...

Exemple de saisie de nombre
Code:

1 2 3 4 5 6 7 8 9 char saisie[100]; int nb; while (1) { fputs("Entrez un nombre :", stdout); // Pourquoi passer par printf() 10 fois plus lourd ??? fgets(saisie, 100, stdin); if (sscanf(saisie, "%d", &nb) > 0) break; // sscanf renvoie le nb d'éléments correctement récupérés printf("La saisie [%s] est incorrecte - Recommencez\n", saisie); }
Donc c'est un petit peu le problème du C. Dès qu'on a une intention un tant soi peu professionnelle, on est confronté à son très bas niveau de codage ce qui oblige à tout écrire soi-même...

PS: le lecteur le plus attentif n'aura pas omis de noter le petit soucis devant l'utilisateur qui entre 500 caractères dans une chaine prévue pour 100. Bien sûr fgets() bloque ce qui dépasse mais ne l'élimine pas du clavier.
La solution est toutefois assez simple: soit on ne change rien et cet utilisateur verra alors s'afficher 4 ou 5 fois le message d'erreur pendant que fgets() traite le buffer stdin à chaque tour de boucle, soit on rajoute après fgets() une petite boucle basée sur un while (fgetc(stdin) != EOF) qui libèrera le clavier de ce qu'il y a en trop.

Citation:
Envoyé par Sve@r
Et une fois le texte récupéré, rien n'interdit de l'analyser pour en extraire les infos demandées. Ce qui, en plus, permet de détecter si l'info y était ou pas. Et ça, sscanf() (scanf depuis une string) sait très bien le faire...

Exemple de saisie de nombre
Code:

1 2 3 4 5 6 7 8 9 char saisie[100]; int nb; while (1) { fputs("Entrez un nombre :", stdout); // Pourquoi passer par printf() 10 fois plus lourd ??? fgets(saisie, 100, stdin); if (sscanf(saisie, "%d", &nb) > 0) break; // sscanf renvoie le nb d'éléments correctement récupérés printf("La saisie [%s] est incorrecte - Recommencez\n", saisie); }
Malheureusement non, sscanf ne sait pas le faire :?
Les fonctions *scanf ne gèrent pas les overflows (l'implémentation de la glibc positionne ERANGE mais ce n'est pas standard). Dans ces cas là tu te prends un UB:

Citation:

Envoyé par ISO/IEC 9899:TC3, 7.19.6.2/10

7.19.6.2 The fscanf function
[...]
10 Except in the case of a % specifier, the input item (or, in the case of a %n directive, the
count of input characters) is converted to a type appropriate to the conversion specifier. If
the input item is not a matching sequence, the execution of the directive fails: this
condition is a matching failure. Unless assignment suppression was indicated by a *, the
result of the conversion is placed in the object pointed to by the first argument following
the format argument that has not already received a conversion result. If this object
does not have an appropriate type, or if the result of the conversion cannot be represented
in the object, the behavior is undefined.

Donc pour extraire un entier on utilise strtol qui propose une vrai gestion des erreurs et qui gère tous les cas.

01/07/2014, 17h30
Tom Dar

Houla, je commence à être un peu perdu mais c'est néanmoins intéressant à comprendre :)
01/07/2014, 17h48
sambia39

+/-

Bonsoir, et désolé d'orienter le débat dans un autre sens, même-ci, il est très pertinent de mentionner les défauts de scanf .
Ceci dit, pas mal de débutant n'ont pas été sensibilisé sur la chose et je pense qu'il est préférable, pour ma part de concevoir des exercices au débutant, qui non seulement incitent l'apprenti à poser des questions pas trop idiotes, mais à comprendre également le choix d'une fonction à défaut de l'autre et l'orienter à écrire du code plus ou moins robuste mais bon ce n'est qu'un avis :calim2:
Cordialement
01/07/2014, 19h18
Bktero

Citation:

Envoyé par Sve@r

Ahah, Bktero t'a introduit en erreur :P
En fait, %f pour un double est accepté au printf parce que printf sait faire la différence entre un float et un double (grace au codage interne de la valeur à afficher)

Arf ! Craquage !

Merci pour cette mise au point :)

Citation:

Envoyé par grim7reaper

Malheureusement non, sscanf ne sait pas le faire :?

Citation:

Envoyé par Envoyé par ISO/IEC 9899:TC3, 7.19.6.2/10

7.19.6.2 The fscanf function
...If this object does not have an appropriate type, or if the result of the conversion cannot be represented in the object, the behavior is undefined.

Zut, l'anglais et moi ça fait 30 donc je pige pas trop bien. Il me semble voir que si une conversion est impossible cela produit un comportement indéterminé. Mais peut-être que convertir une chaine en int ne fait pas partie des cas de "conversions non possibles"...

Par ailleurs, la même norme possède quand-même un paragraphe sur sscanf()

Citation:

Envoyé par Envoyé par ISO/IEC 9899:TC3, 7.19.6.2/10

7.19.6.7 The sscanf function Synopsis
...
The sscanf function returns the value of the macro EOF if an input failure occurs before any conversion. Otherwise, the sscanf function returns the number of input items assigned, which can be fewer than provided for, or even zero, in the event of an early matching failure

Ca indique bien noir sur blanc que sscanf renvoie le nombres d'items qu'il a réussi à récupérer, ou bien 0 s'il n'en récupère aucun.

Vois-tu, ta remarque peut déboucher sur un problème grave parce que cette façon de saisir (fgets() + sscanf()) a été présentée moulte fois sur ce forum comme une façon efficace et robuste ; et par de bien plus grands que moi. S'il s'avérait qu'elle ne soit pas correcte, tout le monde peut se tromper mais cela porterait tout de même un rude coup à la crédibilité de tous les "pros" qui viennent ici aider/conseiller. Se pourrait-il (sans vouloir te vexer) que ta conclusion de ce qui est écrit dans la norme soit erronée ?

Voici un petit code tapé à l'arrache
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 #include <stdio.h> #include <stdlib.h> int main() { char saisie[100]; int nb, x; while (1) { fputs("saisie :", stdout); fgets(saisie, 100, stdin); x=sscanf(saisie, "%d", &nb); printf("result: x=%d, nb=%d\n", x, nb); } }
Et son résultat
Code:

1 2 3 4 5 6 7 8 9 10 11 12 $ ./x saisie :123 result: x=1, nb=123 saisie :aaa result: x=0, nb=123 saisie :xxx result: x=0, nb=123 saisie :456 result: x=1, nb=456 saisie :yyy result: x=0, nb=456 saisie :^C
Bien que cela ne prouve rien, il semblerait que toute saisie non numérique n'affecte pas la variable et fasse renvoyer 0 à sscanf...

Citation:

Envoyé par sambia39

Ceci dit, pas mal de débutant n'ont pas été sensibilisé sur la chose

Ben oui, parce que pas mal de profs ne connaissent même pas la problématique de la chose, ou l'envisagent mal (voir le fflush(stdin) qu'ils n'hésitent pas à proposer comme solution)...

Citation:

Envoyé par sambia39

et je pense qu'il est préférable, pour ma part de concevoir des exercices au débutant, qui non seulement incitent l'apprenti à poser des questions pas trop idiotes, mais à comprendre également le choix d'une fonction à défaut de l'autre et l'orienter à écrire du code plus ou moins robuste

Oui, mais pour écrire du code robuste il faut déjà avoir la connaissance du soucis, la connaissance des outils permettant de le régler (les fonctions fget/fput ne sont vues généralement qu'à partir du chapitre concernant les fichiers donc généralement à la fin) et une bonne habitude du langage et de ses subtilités. Et comme tu peux le voir, même parmis ceux qui ont une bonne habitude, il demeure toujours des manques, des oublis, voire des divergences quant à la façon dont on doit comprendre certains détails précis...

Citation:

Envoyé par Sve@r

Zut, l'anglais et moi ça fait 30 donc je pige pas trop bien. Il me semble voir que si une conversion est impossible cela produit un comportement indéterminé. Mais peut-être que convertir une chaine en int ne fait pas partie des cas de "conversions non possibles"...

"if the result of the conversion cannot be represented in the object, the behavior is undefined." ça signifie que si le résultat de la conversion (donc ça sous-entend que la conversion est réussie) ne peut pas être représenté (comment tu représentes 4 294 967 296 dans un int 32 bit (overflow) ?), et bien tu as un UB.

Citation:

Envoyé par Sve@r

Par ailleurs, la même norme possède quand-même un paragraphe sur sscanf()

Citation:

Envoyé par ISO/IEC 9899:TC3, 7.19.7

7.19.6.7 The sscanf function Synopsis
...
The sscanf function returns the value of the macro EOF if an input failure occurs before any conversion. Otherwise, the sscanf function returns the number of input items assigned, which can be fewer than provided for, or even zero, in the event of an early matching failure

Ca indique bien noir sur blanc que sscanf renvoie le nombres d'items qu'il a réussi à récupérer, ou bien 0 s'il n'en récupère aucun.

Oui et non.
Ça indique que sscanf renvoie le nombre d’éléments assignés (donc converti) avec succès.
Bien, mais le problème que je pointe est une conversion réussie (format %d et la chaîne contient un entier) dont le résultat n’est pas représentable (entier trop grand) dans l’objet de destination.

Citation:

Envoyé par Sve@r

Vois-tu, ta remarque peut déboucher sur un problème grave parce que cette façon de saisir (fgets() + sscanf()) a été présentée moulte fois sur ce forum comme une façon efficace et robuste ; et par de bien plus grands que moi. S'il s'avérait qu'elle ne soit pas correcte, tout le monde peut se tromper mais cela porterait tout de même un rude coup à la crédibilité de tous les "pros" qui viennent ici aider/conseiller.

Je sais que c’est une approche fréquemment recommandée, mais je sais aussi que c’est une facette des *scanf méconnu donc ça ne m'étonne pas plus que ça que même des « grands » se trompent.
Aucune remise en cause de crédibilité, on ne peut pas tout savoir.

Citation:

Envoyé par Sve@r

Se pourrait-il (sans vouloir te vexer) que ta conclusion de ce qui est écrit dans la norme soit erronée ?

Je ne pense pas (je ne me vexe pas pour si peu, ne t’inquiète pas :P).
Autant la norme peut parfois sembler ambigu, autant là je pense ne pas me tromper.
De plus, il y a aussi l’annexe J.2 du même standard :

Citation:

Envoyé par ISO/IEC 9899:TC3, Annex J

J.2 Undefined behavior
[…]
— The result of a conversion by one of the formatted input functions cannot be
represented in the corresponding object, or the receiving object does not have an
appropriate type (7.19.6.2, 7.24.2.2).

(on notera le renvoi à la section 7.19.6.2, celle que j’ai cité précedemment)

Enfin, il y a déjà eu des rapports de bug à ce sujet (ici et là par exemple).
Citation:
Envoyé par Sve@r
Voici un petit code tapé à l'arrache
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 #include <stdio.h> #include <stdlib.h> int main() { char saisie[100]; int nb, x; while (1) { fputs("saisie :", stdout); fgets(saisie, 100, stdin); x=sscanf(saisie, "%d", &nb); printf("result: x=%d, nb=%d\n", x, nb); } }
Et son résultat
Code:

1 2 3 4 5 6 7 8 9 10 11 12 $ ./x saisie :123 result: x=1, nb=123 saisie :aaa result: x=0, nb=123 saisie :xxx result: x=0, nb=123 saisie :456 result: x=1, nb=456 saisie :yyy result: x=0, nb=456 saisie :^C
Bien que cela ne prouve rien, il semblerait que toute saisie non numérique n'affecte pas la variable et fasse renvoyer 0 à sscanf...
Oui, tout saisie non numérique échoue.
Encore une fois, ce n’est pas ce dont je parle.
Je parle d’une conversion réussie mais dont le résultat ne peut pas être représenté.
D’ailleurs, en reprenant ton code, voilà ce que j’obtiens :
Code:

1 2 3 4 5 6 7 8 9 10 11 [grim7reaper@coupable ~] % gcc -o Sve@r Sve@r.c [grim7reaper@coupable ~] % ./Sve@r saisie :1000000000000 result: x=1, nb=-727379968 saisie :^C [grim7reaper@coupable ~] % gcc -o Sve@r Sve@r.c -m32 [grim7reaper@coupable ~] % ./Sve@r saisie :1000000000000 result: x=1, nb=2147483647 saisie :^C [grim7reaper@coupable ~] %
Tu remarqueras que pour un même code, même compilo’, même OS on a un comportement différent (mais un résultat faux dans les 2 cas) selon que l’on soit 32 ou 64 bits (au passage, c’est le second rapport de bug que j’ai linké).
Et c’est tout a fait légal, un UB donne carte blanche au compilo’ (j’ai déjà vu un bool qui valait vrai ET faux simultanément en cas d’UB :P). Il aurait aussi bien pu formater mon PC que me faire sortir des démons du nez.

01/07/2014, 21h42
Bktero

Personnellement, je ne vois pas de faille dans le raisonnement de grim7reaper.

Citation:

Unless assignment suppression was indicated by a *, the
result of the conversion is placed in the object pointed to by the first argument following
the format argument that has not already received a conversion result.

Cela sous-entend que la conversion a réussi. Je me demande d'ailleurs comment on peut juger qu'elle est réussie si on ne peut pas faire rentrer le résultat dans la ""lvalue"".
01/07/2014, 22h51
Sve@r

Citation:

Envoyé par grim7reaper

Encore une fois, ce n’est pas ce dont je parle.
Je parle d’une conversion réussie mais dont le résultat ne peut pas être représenté.

+1. J'étais parti sur une conversion échouée sans regarder l'autre coté :mur: