Ma fonction "détruit" ma variable !

Recherche :

Mot : Pseudo : Filtrer
Bas de page
Auteur	Sujet : Ma fonction "détruit" ma variable !

Slay

Code :

[...]
printf("%s",chemin);
Cree_subi(chemin,subi,(patient.DernierExam)-1);
printf("\n\n\tExamens : \n" );
printf("%s",chemin);
AfficherExamens(chemin,subi);
}
}
printf("\n\nAppuyez sur une touche pour retourner au menu ... " );
getch();
}
void Cree_subi(char *chemin,SUBI_EXAMENS *subi,int ligne)
{
char fichier[20];
FILE *fp;
strcpy(fichier,chemin);
strcat(fichier,"_subi.dat" );
fp=fopen(fichier,"rb" );
while(ligne!=-1)
{
fseek(fp,sizeof(*subi)*ligne,SEEK_SET);
fread(subi,sizeof(*subi),1,fp);
ligne=subi->pointeur;
subi++;
}
fclose(fp);
}

Le premier printf("%s",chemin); se passe sans problème mais le deuxième, mon programme plante ( erreur windows ) , on dirait que la variable chemin s'est "détruite" lors de l'exécution de Creer_subi
Or je ne l'utilise que dans un strcpy , comme deuxième argument, il ne devrait donc subir aucune modif et encore moins devenir "inutilisable"
Quelqu'un à une idée ?

PS : J'utilise Visual C++ 6.0

Merci d'avance , parce que sur ce coup-là ,je bloque

Message édité par Slay le 02-05-2005 à 20:23:29

Publicité

Elmoricq

Modérateur

Elle est déclarée comment ta variable *chemin ?

Et l'erreur quand ça plante, c'est quoi ?

Message édité par Elmoricq le 02-05-2005 à 20:27:32

Slay

Elmoricq a écrit :

Elle est déclarée comment ta variable *chemin ?

Et l'erreur quand ça plante, c'est quoi ? (bien que j'aie mon idée là-dessus)

char [25]

et j'ai une erreur "normal" de windows, "Windows a rencontrer un problème avec le programme ... "
rien de plus

( le pire c'est que je fais des strcpy de cette meme variable à plein d'autres endroits, et jamais eu aucun problème ! )

Elmoricq

Modérateur

C'est quoi ton type SUBI_EXAMENS ?

Slay

Slay a écrit :

je viens de me rendre compte en fesant le debug que ce sont TOUTES mes variables qui s'éfface juste APRES la fin de la fonction :ouch:

=>

+ chemin 0xcccccccc ""
+ index 0xcccccccc
+ fp 0xcccccc00
+ fichier 0x0012fae0 "ÌÌNÌ"
+ patient {...}
+ subi 0x0012f890
j -858993460
i -858993460
ind_pat -858993460

Slay

Elmoricq a écrit :

C'est quoi ton type SUBI_EXAMENS ?

Code :

struct _subi_examens{
int indice;
int Nomenclature;
char NumSis[11];
DATE Date;
char Facture;
int pointeur;
};

mais comme j'ai dis plus haut, toutes mes variables sont affectées ( je m'en étais pas rendu compte au début )

Elmoricq

Modérateur

Clair qu'il y a un problème dans ta boucle.

Déjà j'aime pas ta condition d'arrêt.

Ensuite, tu es sûr de ton "subi++" ?!

Enfin, ta variable "pointeur" qui peut être égale à -1, elle symbolise quoi ?

Message édité par Elmoricq le 02-05-2005 à 20:38:00

++fab

victime du syndrome IH

# char fichier[20];
# FILE *fp;
# strcpy(fichier,chemin);
# strcat(fichier,"_subi.dat" );

Quel est le nombre maximal de caractères que peut contenir "chemin" sans qu'il n' y ait un comportement indéfini ?

Message édité par ++fab le 02-05-2005 à 20:41:44

Slay

Elmoricq a écrit :

le pointeur c'est l'enregistrement suivant , s'il n'en existe pas ,c'est égale à -1

Subi est initialisé dans la fonction précédente et est un vecteur de structure
donc si ligne = -1 ( qui est en réalité que le pointeur vers la structure suivante) cela signifie que l'on est a la fin du chainage

Slay

++fab a écrit :

:cry: 20 également , je viens de tester à 25 et ca fonctionne
je comprend pas pcq dans mes teste mon " chemin " était formé de 11 caractères , je pensais pas que le problème pouvait venir de là, honte à moi :cry:

N'empeche c'est bizzare comment ca bouzillait toutes les variables :ouch: :ouch:

Merci bien , comme quoi des fois c'est vraiment un truc débile :wahoo:

Message édité par Slay le 02-05-2005 à 20:45:43

Publicité

++fab

victime du syndrome IH

prend un chemin de 20 caracteres par exemple, et ça ne fonctionnera plus à nouveau. Pourquoi ? refléchit un peu à ça :
# strcpy(fichier,chemin);
# strcat(fichier,"_subi.dat" ); *
demande toi combien de caractères a "fichier" à chaque instruction.

Message édité par ++fab le 02-05-2005 à 20:50:15

Slay

++fab a écrit :

oui exact
je viens de penser que le faite que les variables "plantaient" , vu que je dépassais la taille prévue j'allais écrire sur les autres variables dans la mémoire

ps : comme quoi l'assembleur ca permet de comprendre certaines choses [:aloy]

++fab

victime du syndrome IH

bravo, c'est ce qui provoquait ce comportement indéfini.
Maintenant, à toi de jouer pour trouver la parade

skelter

Slay a écrit :

N'empeche c'est bizzare comment ca bouzillait toutes les variables :ouch: :ouch:

que voila un magnifique buffer overflow

Code :

void Cree_subi(char *chemin,SUBI_EXAMENS *subi,int ligne)
{
char fichier[20];
strcpy(fichier,chemin);
}

tu as l'âme d'un cracker ?

lors de l'appel de la fonction, les parametres, ..., les variables locales sont empilés par adresse decroissantes, ce qui fais qu'un overflow sur le tableau fichier corrompt ta pile en ecrivant vers les parametres.

l'article sur wikipedia
http://fr.wikipedia.org/wiki/D%C3% [...] _de_tampon

Slay

skelter a écrit :

que voila un magnifique buffer overflow

Code :

void Cree_subi(char *chemin,SUBI_EXAMENS *subi,int ligne)
{
char fichier[20];
strcpy(fichier,chemin);
}

le pire c'est que je le savais bien [:totoz] mais je n'y avais pas pensé [:jkley]

Edit : je savais pas que cela se fesait aussi facilement en C, en ASM en 2 lignes c'est fait mais je croyais que le C protégait un peu plus

Message édité par Slay le 02-05-2005 à 21:05:48

Emmanuel Delahaye

C is a sharp tool

Slay a écrit :

Je n'ai pas bien compris ce que tu voulais faire, mais déjà je travaillerais un peu plus dans la sécurité :

#include <stdlib.h>
#include <stdio.h>
#include <string.h>

typedef struct
{
int indice;
int Nomenclature;
char NumSis[11];
char Facture;
int pointeur;
}
SUBI_EXAMENS;

void Cree_subi (char const *chemin, SUBI_EXAMENS * subi)
{
#define F "_subi.dat"
char fichier[20];

if (strlen (chemin) + sizeof F <= sizeof fichier)
{
strcpy (fichier, chemin);
strcat (fichier, F);

printf ("Ouverture de '%s'\n", fichier);

FILE *fp = fopen (fichier, "rb" );

if (fp != NULL)
{
do
{
fread (subi, sizeof *subi, 1, fp);
}
while (subi->pointeur != -1);

fclose (fp);
}
else
{
perror (fichier);
}
}
else
{
fprintf (stderr, "ERR : chemin trop long\n" );
}
}

void AfficherExamens (char *chemin, SUBI_EXAMENS * subi)
{
#define PRT_I(f) \
printf ("%-10s = %d\n", #f, subi->f)

#define PRT_S(f) \
printf ("%-10s = %s\n", #f, subi->f)

PRT_I (indice);
PRT_I (Nomenclature);
PRT_S (NumSis);
PRT_I (Facture);
PRT_I (pointeur);

}

int main (void)
{
char chemin[25] = "../";
SUBI_EXAMENS subi_;
SUBI_EXAMENS *subi = &subi_;

struct patient
{
int DernierExam;
}
patient =
{
1
};

Cree_subi (chemin, subi);
printf ("\n\n\tExamens : \n" );
AfficherExamens (chemin, subi);

return 0;
}

Modifie ce code pour être conforme à ce que tu fais et fourni un moyen de créer le fichier de données...

---------------
Des infos sur la programmation et le langage C: http://www.bien-programmer.fr Pas de Wi-Fi à la maison : http://www.cpl-france.org/

skelter

Slay a écrit :

Edit : je savais pas que cela se fesait aussi facilement en C, en ASM en 2 lignes c'est fait mais je croyais que le C protégait un peu plus

ben la puissance et la flexibilité du C se paye par aucun controles de bord

edit: le C c'est juste un asm de haut niveau
edit2: et portable

Message édité par skelter le 02-05-2005 à 21:09:28

Slay

skelter a écrit :

ben la puissance et la flexibilité du C se paye par aucun controles de bord

edit: le C c'est juste un asm de haut niveau
edit2: et portable

enfin bon , en gros j'aurai pu faire planté la machine si mon overflow était beaucoup plus important ( sauf si windows, lui, protège les endroits "critiques" de la mémoire )

++fab

victime du syndrome IH

Un processus dispose de son propre espace d'adressage [:adodonicoco] (pas de tout temps, mais aujourd'hui oui )
Donc pour répondre à ta question : non

Emmanuel Delahaye

C is a sharp tool

Slay a écrit :

je savais pas que cela se fesait aussi facilement en C, en ASM en 2 lignes c'est fait mais je croyais que le C protégait un peu plus

Non. En C, rien ne te protège d'un comportement indéfini. Il peut arriver n'importe quoi.

Message édité par Emmanuel Delahaye le 02-05-2005 à 21:19:43

---------------
Des infos sur la programmation et le langage C: http://www.bien-programmer.fr Pas de Wi-Fi à la maison : http://www.cpl-france.org/

++fab

victime du syndrome IH

Emmanuel Delahaye a écrit :

Non. En C, rien ne te protège d'un comportement indéfini. Il peut arriver n'importe quoi.

Si, une vieille barbe de 68ard [:petrus75]

Publicité

FORUM HardWare.fr

Programmation

Ma fonction "détruit" ma variable !

Sujets relatifs
Aide au débugage - Comportement bizare d'une fonction...	Séparation d'une variable date 1902 en 19 et 02 comment ?
[RESOLU][XSL]Creer un variable pour mettre un width="" pour un table	pb variable et hyperlien
Variable d'environnement	UPLOAD de fichier fonction ftp
variable dynamique	Fonction call?
[Flash] problème avec la fonction hitTest (problème illustré)	fonction pour afficher tous les éléments d'une méthode POST.
Plus de sujets relatifs à : Ma fonction "détruit" ma variable !

Page générée en 0.109 secondes