Discussion :

[fx007]

Bonjour

Je viens de trouver un problème assez bizarre dans un simple code qui est censé afficher une chaine de caractères que je récupère avec gets.
Je vous met le petit code que j'ai trouvé:

Code :

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

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
#include<iostream>
 
int main()
{
	try
	{
		// *vars
		char print='N';
		char text_chars[10];
 
		// *get text
		printf("Enter text : ");
		gets(text_chars);
 
		// *print out
		if(print=='O')
		{
			printf("I read : %s\n",text_chars);
			getchar();
		}
		else
		{
			printf("Unreachable code\n");
			getchar();
		}
	}
	catch(...)
	{
	}
	exit(0);
}

A première vu peu importe la chaine que l'on rentre, il ira toujours dans le bloc else pour afficher à l'ecran "unreachabe code".

Or on m'a fait essayer la chaine ci-contre: abcdefghijklmnopqrstuvwOyz et il se trouve qu'il va dans le bloc if... Et là je n'arrive pas à comprendre pourquoi. D'ailleurs peu importe la combinaison de lettre, si à la 24è on a un O alors il ira dans la condition "if".

Si quelqu'un a une réponse à ce problème, je suis preneur !!

Merci!

Fx007

[Laurent Gomila]

Essaye déjà de commencer par ne pas saisir 24 caractères dans un tableau qui ne peut en contenir que 10

Ensuite, en C++ on utilise cout et cin, pas printf et gets.

[fx007]

Essaye déjà de commencer par ne pas saisir 24 caractères dans un tableau qui ne peut en contenir que 10

Ensuite, en C++ on utilise cout et cin, pas printf et gets.

Merci pour ta réponse... et je pensais bien que quelqu'un allait me parler du tableau de 10 caractères mais c'est tout de même bizarre qu'il aille dans l'une des conditions alors que je devrais avoir un problème de segmentation par exemple.

Mais au-delà de ce problème de mémoire et de la syntaxe transposé du C, n'y a t-il pas une autre raison à ce "problème"?

[Laurent Gomila]

Un comportement indéfini, comme son nom l'indique, amène le programme à se comporter de manière non prévisible. Ca peut n'avoir aucun rapport avec ce que tu constates, comme ça peut en avoir (après tout, qui sait ce qui se trouve derrière ton tableau en mémoire ?).

Donc avant d'aller plus loin, élimine ce comportement indéfini pour que l'on puisse réflechir sur des bases correctes.

[koala01]

Salut,

Comme Laurent l'a signalé, tu crées un comportement indéfini...

Si tu tiens à une explication sensée (qui ait un sens, à défaut d'être logique), tu peux *estimer* que l'adresse à laquelle se trouve print correspond à l'adresse du début de text_char +23, et que le fait d'introduire ... 24 caractères là où 10 sont seulement possible ira "chatouiller" le contenu de ta variable print.

Dés lors, si le 24eme caractère est un "O", ben le test se mettra "par magie" à donner un résultat vrai.

C'est l'un des principaux reproches que l'on puisse faire en C, et la preuve flagrante que 90% des bugs trouvent leurs origines entre le clavier et l'assise de la chaise (finalement: c'est l'utilisateur qui décidera d'introduire... 24 caractères alors qu'on ne lui en demande que 10... à moins que ce soit à cause du programmeur qui ne sécurise pas suffisamment sa saisie )

Cependant, il faut bien être conscient que cette réflexion ne s'applique que sur ce cas bien précis, dans cette situation particulière...

C'est la raison pour laquelle, en C++, on préférera fortement utiliser la classe string, disponible dans l'espace de nommage std par inclusion du fichier <string>, qui a l'énorme avantage d'éviter les "débordements de mémoire" (le fait qu'un ou plusieurs caractères n'aillent se placer à une adresse mémoire à laquelle ils ne devraient normalement pas se trouver) qui sont, entre autre, responsables du comportement observé ici...

[droggo]

Mio,

finalement: c'est l'utilisateur qui décidera d'introduire... 24 caractères alors qu'on ne lui en demande que 10... à moins que ce soit à cause du programmeur qui ne sécurise pas suffisamment sa saisie

Je penche pour cette explication : un programme doit résister à toutes les erreurs de saisie prévisibles, et comme il en est forcément qui ne le sont pas, au moins réagir proprement dans ces cas là.