stack smashing detected

Le
bpascal123
Je vais essayer de trouver l'erreur avant de lire vos réponses et/ou
conseils que j'accueillerais avec plaisir. Sur les résultats de
google, stack smashing detected semble être une erreur dure à trouver.
Pour le code ci-dessous, c'est un exercice que j'ai écris une dizaine,
vingtaine de fois voire +. Mais ça fait déjà quelques semaines et je
ne sais plus où sont les fichiersEn plus, il y a de nombreuses
façons différentes d'écrire, lire un fichier en tant que débutant a=
vec
des fonctions simples

Le code où se trouve l'erreur :

/*
* lire data15a.txt et supprimer les enreg. dont le no. est inferieur a
5 et copier
* dans data15rev.txt
*/

#include <stdio.h> /* printf fprintf fscanf fopen fclose fgetc feof
*/
#include <stdlib.h> /* exit */

#define CRECMAX 10 /* nbr d'enreg. max */
#define CTXTMAXL 20 /* long. de caracteres max */

void ReadFile(FILE *FP_FILE) ;
void ReadDelCopyFile(FILE *FP_SOURCE, FILE *FP_DEST) ;
void OpenFile(FILE *FP_FILE) ;

int main(void)
{
FILE *MP_SOURCE = NULL ;
FILE *MP_DESTI = NULL ;
char MPSource[] = "/media/XP/code_c/data15a.txt" ;
char MPDesti[] = "/media/XP/code_c/data15rev.txt" ;

printf("Debut du programme") ;

printf("Ouverture de "data15a.txt" : ") ;
MP_SOURCE = fopen(MPSource, "r") ;
OpenFile(MP_SOURCE) ;

printf("Ouverture de "data15rev.txt" : ") ;
MP_DESTI = fopen(MPDesti, "w") ;
OpenFile(MP_DESTI) ;

ReadDelCopyFile(MP_SOURCE, MP_DESTI) ;

ReadFile(MP_DESTI) ;

printf("") ;
return 0 ;
}

void ReadDelCopyFile(FILE *FP_SOURCE, FILE *FP_DESTI)
{
int i ;
int FNum[CRECMAX] ;
char FTxt1[CTXTMAXL] ;
char FTxt2[CTXTMAXL] ;

while(!feof(FP_SOURCE))
{
if (fscanf(FP_SOURCE, "%d%s%s", &FNum[i], FTxt1, FTxt2) == 3)
if (FNum[i] > 5)
{
fprintf(FP_DESTI, "%d%s%s", FNum[i], FTxt1, FTxt2) ;
i++ ;
}
}
}

void ReadFile(FILE *FP_FILE)
{
int c ;
printf("") ;
while ((c = getc(FP_FILE) != EOF))
putc(c, FP_FILE) ;
}

void OpenFile(FILE *FP_FILE)
{
if (!FP_FILE)
{
printf("Erreur ouverture de fichier!") ;
exit(EXIT_FAILURE) ;
}
else
printf("Ouverture reussie.") ;
}


Le message d'erreur lors de l'execution (pas de message dans la phase
de compilation) :

Ouverture reussie.
*** stack smashing detected ***: ./exdiv3w terminated
= Backtrace:
/lib/tls/i686/cmov/libc.so.6(__fortify_fail+0x48)[0x2f2008]
/lib/tls/i686/cmov/libc.so.6(__fortify_fail+0x0)[0x2f1fc0]
./exdiv3w[0x804883a]
./exdiv3w[0x804874c]
/lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xe6)[0x227b56]
./exdiv3w[0x8048591]
= Memory map: ==
00211000-0034f000 r-xp 00000000 08:06 5269 /lib/tls/i686/cmov/
libc-2.10.1.so
0034f000-00350000 p 0013e000 08:06 5269 /lib/tls/i686/cmov/
libc-2.10.1.so
00350000-00352000 r--p 0013e000 08:06 5269 /lib/tls/i686/cmov/
libc-2.10.1.so
00352000-00353000 rw-p 00140000 08:06 5269 /lib/tls/i686/cmov/
libc-2.10.1.so
00353000-00356000 rw-p 00000000 00:00 0
00575000-00591000 r-xp 00000000 08:06 3651 /lib/libgcc_s.so.1
00591000-00592000 r--p 0001b000 08:06 3651 /lib/libgcc_s.so.1
00592000-00593000 rw-p 0001c000 08:06 3651 /lib/libgcc_s.so.1
00baa000-00bc5000 r-xp 00000000 08:06 7860 /lib/ld-2.10.1.so
00bc5000-00bc6000 r--p 0001a000 08:06 7860 /lib/ld-2.10.1.so
00bc6000-00bc7000 rw-p 0001b000 08:06 7860 /lib/ld-2.10.1.so
00e55000-00e56000 r-xp 00000000 00:00 0 [vdso]
08048000-08049000 r-xp 00000000 08:01 35163 /media/XP/code_c/
exdiv3w
08049000-0804a000 r--p 00000000 08:01 35163 /media/XP/code_c/
exdiv3w
0804a000-0804b000 rw-p 00001000 08:01 35163 /media/XP/code_c/
exdiv3w
099c1000-099e2000 rw-p 00000000 00:00 0 [heap]
b780e000-b780f000 rw-p 00000000 00:00 0
b781f000-b7824000 rw-p 00000000 00:00 0
bfae5000-bfafa000 rw-p 00000000 00:00 0 [stack]
Aborted

merci pour votre aide
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses Page 1 / 2
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
espie
Le #22628641
In article
Je vais essayer de trouver l'erreur avant de lire vos réponses et/ou
conseils que j'accueillerais avec plaisir. Sur les résultats de
google, stack smashing detected semble être une erreur dure à trouver.
Pour le code ci-dessous, c'est un exercice que j'ai écris une dizaine,
vingtaine de fois voire +. Mais ça fait déjà quelques semaines et je
ne sais plus où sont les fichiers...En plus, il y a de nombreuses
façons différentes d'écrire, lire un fichier en tant que débutant avec
des fonctions simples...



Compile avec -g, ca sera plus facile a voir dans le backtrace.

Le code où se trouve l'erreur :
void ReadDelCopyFile(FILE *FP_SOURCE, FILE *FP_DESTI)
{
int i ;
int FNum[CRECMAX] ;
char FTxt1[CTXTMAXL] ;
char FTxt2[CTXTMAXL] ;

while(!feof(FP_SOURCE))
{
if (fscanf(FP_SOURCE, "%d%s%s", &FNum[i], FTxt1, FTxt2) == 3)
if (FNum[i] > 5)
{
fprintf(FP_DESTI, "%dn%sn%sn", FNum[i], FTxt1, FTxt2) ;
i++ ;
}
}
}




La seule fonction ou tu as des variables automatiques tableau...

ce que te dis le compilo, c'est que tu ecris en dehors de tes tableaux.

Regarde attentivement ton code, l'erreur est evidente...

Si tu ne vois pas, utilise les bons drapeaux de compilation, typiquement
-Wall pour avoir le maximum de warnings, et -O2 pour forcer le compilo
a faire un peu d'analyse de code.

Et la il va te dire un truc sur cette fonction. ;-)
-ed-
Le #22628831
On 30 sep, 03:45, ""

void ReadDelCopyFile(FILE *FP_SOURCE, FILE *FP_DESTI)
{
        int i ;
        int FNum[CRECMAX] ;
        char FTxt1[CTXTMAXL] ;
        char FTxt2[CTXTMAXL] ;

        while(!feof(FP_SOURCE))
        {
                if (fscanf(FP_SOURCE, "%d%s%s", &FNum[i], FTxt1, FTxt2) == 3)




On a pourtant essayé 40000 fois de t'expliquer que ce n'est pas comme
ça qu'on lit un fichier, mais tu es plus têtu qu'une cohorte
d'ânes ...

Que faire devant ce mur d'inertie ...
bpascal123
Le #22631391
Que faire devant ce mur d'inertie ...



Je peux comprendre votre remarque. Pour me défendre, je veux dire que
la programmation n'est pas une matière avec un et un seul chemin. Peut-
être je n'ai pas pris le bon chemin avec le code et la lecture d'un
fichier. A mon niveau, je suis satisfait quand un code qui fait appel
à une certaine technique fonctionne et me semble cohérent.

En tant que débutant, je n'ai pas le temps de prendre assez de recul
pour considérer quelque chose plutôt qu'une autre chose. Comme votre
remarque à l'air sérieuse je vais relire les posts précédenst, essa yer
de retrouver votre réponse et comprendre la remaque que vous venez de
faire.

En même temps, je suis pressé de passer aux chapitres suivants et sans
le vouloir je recule pour mieux sauter. C'est pour dire qu'arriver au
chapitre structure chainer, écriture-lecture de fichier..., je
comprendrais que je n'ai pas été assez attentif dans un chapitre
précédent.

Merci pour ce rappel même si vous y aller un peu fort.
bpascal123
Le #22631601
Voilà pour le backtrace :

:/media/XP/code_c$ gcc exdiv3w.c -o -g exdiv3w
exdiv3w: In function `ReadDelCopyFile':
(.text+0x20d): multiple definition of `ReadDelCopyFile'
/tmp/ccohYJhE.o:exdiv3w.c:(.text+0x159): first defined here
exdiv3w: In function `_start':
/build/buildd/eglibc-2.10.1/csu/../sysdeps/i386/elf/start.S:65:
multiple definition of `_start'
/usr/lib/gcc/i486-linux-gnu/4.4.1/../../../../lib/crt1.o:/build/buildd/
eglibc-2.10.1/csu/../sysdeps/i386/elf/start.S:65: first defined here
exdiv3w:(.rodata+0x0): multiple definition of `_fp_hw'
/usr/lib/gcc/i486-linux-gnu/4.4.1/../../../../lib/crt1.o:(.rodata
+0x0): first defined here
exdiv3w: In function `_fini':
(.fini+0x0): multiple definition of `_fini'
/usr/lib/gcc/i486-linux-gnu/4.4.1/../../../../lib/crti.o:(.fini+0x0):
first defined here
exdiv3w: In function `ReadFile':
(.text+0x2cc): multiple definition of `ReadFile'
/tmp/ccohYJhE.o:exdiv3w.c:(.text+0x218): first defined here
exdiv3w:(.rodata+0x4): multiple definition of `_IO_stdin_used'
/usr/lib/gcc/i486-linux-gnu/4.4.1/../../../../lib/crt1.o:
(.rodata.cst4+0x0): first defined here
exdiv3w: In function `__data_start':
(.data+0x0): multiple definition of `__data_start'
/usr/lib/gcc/i486-linux-gnu/4.4.1/../../../../lib/crt1.o:(.data+0x0):
first defined here
exdiv3w: In function `__data_start':
(.data+0x4): multiple definition of `__dso_handle'
/usr/lib/gcc/i486-linux-gnu/4.4.1/crtbegin.o:(.data+0x0): first
defined here
exdiv3w: In function `OpenFile':
(.text+0x311): multiple definition of `OpenFile'
/tmp/ccohYJhE.o:exdiv3w.c:(.text+0x25d): first defined here
exdiv3w: In function `main':
(.text+0xb4): multiple definition of `main'
/tmp/ccohYJhE.o:exdiv3w.c:(.text+0x0): first defined here
exdiv3w: In function `_init':
(.init+0x0): multiple definition of `_init'
/usr/lib/gcc/i486-linux-gnu/4.4.1/../../../../lib/crti.o:(.init+0x0):
first defined here
/usr/lib/gcc/i486-linux-gnu/4.4.1/crtend.o:(.dtors+0x0): multiple
definition of `__DTOR_END__'
exdiv3w:(.dtors+0x4): first defined here
collect2: ld returned 1 exit status

quelques minutes après le copié-collé :
je viens de trouver l'erreur de stack smashing detected, c'est dans la
fonction ReadDelCopyFile, je n'affecte pas i = 0 avant while...donc i
peut contenir une valeur aléatoire qui peut se trouver dans le
stack???

questions (pas de réponse dans google):
-Quelle est la différence entre "stack smashing deteced" et
"segmentation fault"? Je me demande aussi si stack smashing... ne
vient pas d'apparaître avec une mise à jour de gcc dans ubuntu car
depuis 1an, je rencontre ce message pour la première fois...On peut
retrouver cette erreur dans la norme?

-est-ce qu'il faut comprendre l'assembleur pour lire les messages
d'erreurs ci-dessus et comprendre de quoi il s'agit? Avec 2-4 heures
par semaine au détriment de faire des exercices en C, est-ce que je
peux apprendre les bases de l'assembleur et est-ce que ça sera utile?

Denière chose ; rien ne se produit avec :

void ReadFile(FILE *FP_FILE)
{
int c ;

while ((c = getc(FP_FILE) != EOF))
fputc(c, stdout) ;
}

Je n'ai très certainement pas suivi quelque chose dans les posts
précédents. Mais à ce moment, ça devait fonctionner et maintenant c e
n'est plus le cas! Peut-être par entetement, je n'ai pas fais
attention à quelque chose que quelqu'un aurait pu me dire.

Merci de m'indiquer si c'est le cas, en recherchant ça restera un
souvenir plus long que les quelques jours que ma mémoire me permet de
me souvenir d'un code à moins de prendre un marteau et d'apprendre par
coeur, ce qu'il m'arrive de faire...
espie
Le #22632021
In article
Voilà pour le backtrace :



Mais t'es vraiment un double gros boulet. C'est pas un backtrace.
Le terme backtrace est employe dans ce que tu as poste, juste apres ton
erreur de runtime.

:/media/XP/code_c$ gcc exdiv3w.c -o -g exdiv3w


cette ligne de commande est grotesquement fausse, et donc aucun des messages
d'erreur n'y a de sens.
-o -g -> t'es en train de fabriquer un executable qui s'appelle -g
exdiv3w.c exdiv3w -> en combinant le programme deja existant exdiv3w avec
une recompile de lui-meme.
exdiv3w: In function `ReadDelCopyFile':
(.text+0x20d): multiple definition of `ReadDelCopyFile'
/tmp/ccohYJhE.o:exdiv3w.c:(.text+0x159): first defined here
exdiv3w: In function `_start':


...
pas etonnant que tu aies une tripotee de doubles definitions.

Et le -O2 -Wall ? ca fait combien de putains de messages qu'on te dit de
compiler avec les warnings.

quelques minutes après le copié-collé :
je viens de trouver l'erreur de stack smashing detected, c'est dans la
fonction ReadDelCopyFile, je n'affecte pas i = 0 avant while...donc i
peut contenir une valeur aléatoire qui peut se trouver dans le
stack???


Et voila. Mais t'es maso. Si tu suivais les indications qu'on te donne,
tu l'aurais trouvee avant.

questions (pas de réponse dans google):
-Quelle est la différence entre "stack smashing deteced" et
"segmentation fault"?


Ca depend du moment ou les merdes que tu as ecrites se devoilent.

Je me demande aussi si stack smashing... ne
vient pas d'apparaître avec une mise à jour de gcc dans ubuntu car
depuis 1an, je rencontre ce message pour la première fois...On peut
retrouver cette erreur dans la norme?



Deuxieme reflexion pas trop debile: c'est un filet de sauvetage pour
les neuneus dans ton genre.

Tu peux retrouver cette erreur sous le nom de "undefined behavior" avec
quelques autres. Ton systeme, dans sa grande mansuetude, est un peu plus
precis que "il y a une erreur quelque part" (e.g., c'est pas Access).

-est-ce qu'il faut comprendre l'assembleur pour lire les messages
d'erreurs ci-dessus et comprendre de quoi il s'agit? Avec 2-4 heures
par semaine au détriment de faire des exercices en C, est-ce que je
peux apprendre les bases de l'assembleur et est-ce que ça sera utile?



Apprend deja la base des options des commandes et evite de taper n'importe
quoi.


Bref, la ligne de commande que tu aurais du taper, c'est
:/media/XP/code_c$ gcc exdiv3w.c -o -g exdiv3w


gcc -o exdiv3w -g -O2 -Wall exdiv3w.c

deja, gcc t'aurais dit que i n'est pas initialise dans la fonction.
Et ensuite en le lancant tu aurais obtenu un BACKTRACE qui ne s'arrete
pas dans la fonction de stack-smashing de la libc, mais qui remonte dans
ton programme et te donne precisement la fonction ou ca merde.

Bon, a cote de ca, tu utilises toujours des noms de variable en majuscule,
et tu ne lis pas avec suffisamment d'attention la moitie des trucs qu'on
te dit. Il y a un moment ou le debutant perpetuel, c'est fatigant. Sauf
si tu nous sors un certificat medical indiquant que tu as un deficit notable
d'attention, la j'avoue que j'en ai ma claque...

Je recommencerai peut-etre a te lire quand tu auras une hygiene de travail
raisonnable...
Samuel DEVULDER
Le #22632231
Le 01/10/2010 00:01, a écrit :

questions (pas de réponse dans google):
-Quelle est la différence entre "stack smashing deteced" et
"segmentation fault"? Je me demande aussi si stack smashing... ne
vient pas d'apparaître avec une mise à jour de gcc dans ubuntu car
depuis 1an, je rencontre ce message pour la première fois...On peut
retrouver cette erreur dans la norme?



C'est pas dans la norme. C'est ton OS qui vient de detecter que ton
executable vient de corrompre un bout de la mémoire et le termine. Si
cette zone mémoire est autour de la pile il semble t'afficher un
stack-smashed, sinon un autre message (segfault si la zone mémoire n'est
pas mappée en mémoire physique par exemple).

Sur les OS ou il n'y a pas ces protections mémoire, rien ne stoppe ton
prog qui va corrompre la mémoire des autres progs, voir les infos de
l'os et faire planter complétement l'ordi.

-est-ce qu'il faut comprendre l'assembleur pour lire les messages
d'erreurs ci-dessus et comprendre de quoi il s'agit? Avec 2-4 heures



nan... Tu n'a qu'à retenir que ton OS te dit que ton prog a merdé. A la
limite si tu as un fichier core qui a été généré, tu peux lancer une
analyse post-mortem de ton exe avec gdb. Pour peu que tu ais compilé
avec les infos de débug, il t'indiquera probablement quelle ligne du
code vient de taper en zone mémoire interdite.

sam.
Antoine Leca
Le #22632461
écrivit :
-Quelle est la différence entre "stack smashing deteced" et
"segmentation fault"?



La vraie raison d'être de "stack smashing detected", c'est la protection
contre les débordements de tampon utilisés comme technique
d'infiltration de code ; mais les mécanismes qui déclenchent les deux
exceptions sont les mêmes : des erreurs concernant un pointeur dirigé
vers un emplacement en pile, qui donnaient auparavant "faute de
segmentation" (un terme générique issu de l'architecture du PDP11), sont
maintenant diagnostiquées avec "stack smashing detected", avec un effet
similaire. En fait, c'est une aide à la programmation, cela t'indique
que tu as probablement un pointeur vers une variable en pile qui a
dérivé (le cas le plus fréquent chez les débutants étant d'essayer de
retourner un pointeur vers une variable locale).


Je me demande aussi si stack smashing... ne vient pas d'apparaître



Non, rien à voir.

je rencontre ce message pour la première fois...



Ce n'est pas anormal : tu n'es pas censé faire ce genre d'erreur tous
les jours.

On peut retrouver cette erreur dans la norme?



Non, c'est du spécifique Linux.


-est-ce qu'il faut comprendre l'assembleur pour lire les messages
d'erreurs ci-dessus et comprendre de quoi il s'agit?



Non, l'assembleur ne rentre pas en ligne ici. Ce sont des messages de
l'éditeur des liens, qui s'est bloqué parce que tu as essayé de lier
ensemble la nouvelle version de ton programme (issu de la compilation de
exdiv3w.c) et la version précédente (dans exdiv3w), ce qui donne des
doubles définitions de certaines fonctions.

Avec 2-4 heures
par semaine au détriment de faire des exercices en C, est-ce que je
peux apprendre les bases de l'assembleur et est-ce que ça sera utile?



Non et sûrement pas : le langage d'assemblage est un dinosaure qui n'a
plus vraiment de nécessité pour 99 % des programmeurs... depuis Unix V7
en 1978.


Denière chose ; rien ne se produit avec :

void ReadFile(FILE *FP_FILE)
{
int c ;

while ((c = getc(FP_FILE) != EOF))
fputc(c, stdout) ;
}



FP_FILE est-il ouvert en lecture, et contient-il des caractères à lire?
Comme je ne vois pas de fopen, ici il manque quelque chose au programme
minimum permettant de pouvoir d'aider efficacement.


Antoine
candide
Le #22637571
Antoine Leca a écrit :

Non et sûrement pas : le langage d'assemblage est un dinosaure qui n'a
plus vraiment de nécessité pour 99 % des programmeurs... depuis Unix V7
en 1978.





Pierre Maurette appréciera :) mais 1%, c'est l'élite !!!!
bpascal123
Le #22641851

FP_FILE est-il ouvert en lecture, et contient-il des caractères à lir e?
Comme je ne vois pas de fopen, ici il manque quelque chose au programme
minimum permettant de pouvoir d'aider efficacement.

Antoine



En effet, il manque fclose et fopen en mode lecture et accessoirement
fclose. Mais même avec, la fonction de lecture plante ou alors il y a
un ÿ à la fin lors de la lecture sur l'écran... Je vais revoir dans
les posts précédents s'il y n'y a pas eu un conseil que j'ai passé
sans donner d'importance parce que je n'avais pas donné la priorité à
la lecture écran. C'était plutôt au niveau de fscanf et des
enregistrements... Il y avait une réponse de Ed avec des directives
préprocesseur :

#if 0
/* cette fonction affiche le tout : alors le fichier est lisible */
void DisplayRec (FILE * FP_DESTI)
{
int c;
printf ("nnAFFICHAGE : n");
while ((c = getc (FP_DESTI)) != EOF)
putchar (c);
}

#endif

Mais je n'ai pas encore abordé les directives du préprocesseur (si
c'est bien de ça qu'il s'agit) et puis je ne trouve pas leur emploi
très simple... Mais si je dois me mettre à l'assembleur, je devrais
apprendre à jongler. Si j'apprends l'assembleur par simple curiosité,
je sais que je m'engage pour plusieurs années sans trop savoir où je
vais. Je sais que même avec beaucoup d'effort, je ne pourrais pas
arriver à la cheville d'une personne formée avec de l'expérience dans
ce domaine. Je dois d'abord finir d'apprendre les bases du langage c
et il me semble qu'il reste encore du chemin et le plus dure est
d'ailleurs de combler les lacunes plutôt que d'avancer chapitre après
chapitre.

Pour en revenir à fopen, je trouve d'ailleurs assez dangereux la
fonction fopen en mode écriture.
Pour un fichier quelconque, fopen en mode écriture ouvre le fichier,
efface ce qu'il y a dedans tout en laissant le fichier intact du point
de vue de sa forme (l'icone existe toujours).

Merci
-ed-
Le #22642471
On 4 oct, 00:52, ""

En effet, il manque fclose et fopen en mode lecture et accessoirement
fclose.



Pourquoi 'accessoirement' ? Un fichier ouvert, même en lecture, subit
des modifications (comme la date du dernière accès, par exemple). Il
est donc important de le fermer correctement après usage. C'est du
simple bon sens. J'ouvre, je referme. Point.


Mais même avec, la fonction de lecture plante ou alors il y a
un ÿ à la fin lors de la lecture sur l'écran...



Pour la énième fois, ton mécanisme de lecture est faux. Il faut teste r
la valeur retournée par la fonction de lecture. Relire la doc encore
et encore. Si tu ne la comprends pas, pose des questions précises,
mais cesse de bricoler. C'est pas comme ça qu'on apprend un langage.

Je vais revoir dans
les posts précédents s'il y n'y a pas eu un conseil que j'ai passé
sans donner d'importance parce que je n'avais pas donné la priorité à
la lecture écran. C'était plutôt au niveau de fscanf et des
enregistrements... Il y avait une réponse de Ed avec des directives
préprocesseur :

#if 0
/* cette fonction affiche le tout : alors le fichier est lisible */
void DisplayRec (FILE * FP_DESTI)
{
   int c;
   printf ("nnAFFICHAGE : n");
   while ((c = getc (FP_DESTI)) != EOF)
      putchar (c);

}

#endif

Mais je n'ai pas encore abordé les directives du préprocesseur (si
c'est bien de ça qu'il s'agit) et puis je ne trouve pas leur emploi
très simple...



Je ne me souviens plus avoir ajouté cette directive mais c'est bien
mon style pour isoler (provisoirement et de manière réversible :
remplacer 0 par 1) une portion de code.

Mais si je dois me mettre à l'assembleur, je devrais
apprendre à jongler. Si j'apprends l'assembleur par simple curiosité,



Qu'est-ce que l'assembleur vient faire dans cette galère ? Une chose à
la fois. Tu veux apprendre le C, fait le déjà correctement. On a pas
du tout besoin de connaitre l'assembleur pour faire du C (même si
certains principes peuvent aider à comprendre les pointeurs, comme les
modes d'adressages indirect, mais ça a aussi vite fait d'embrouiller)

je sais que je m'engage pour plusieurs années sans trop savoir où je
vais.



Ca, c'est grave. Pour apprendre le C, il faut 6 mois à 1 an, guère
plus.

Je sais que même avec beaucoup d'effort, je ne pourrais pas
arriver à la cheville d'une personne formée avec de l'expérience da ns
ce domaine. Je dois d'abord finir d'apprendre les bases du langage c
et il me semble qu'il reste encore du chemin et le plus dur est
d'ailleurs de combler les lacunes plutôt que d'avancer chapitre après
chapitre.



SI tu as des difficultés sur des points précis, pose des questions
précises, mais cesse de bricoler. Ça ne résout rien et ça génèr e de
nouvelles questions ...

L'expérimentation en informatique sert à vérifier, s'approprier,
valider un principe connu. Ça ne sert pas à découvrir je ne sais
quoi.

Pour en revenir à fopen, je trouve d'ailleurs assez dangereux la
fonction fopen en mode écriture.
Pour un fichier quelconque, fopen en mode écriture ouvre le fichier,
efface ce qu'il y a dedans tout en laissant le fichier intact du point
de vue de sa forme (l'icone existe toujours).



Plus que jamais, "C is a sharp tool". fopen() avec "w" ou "wb", oui,
ca fait ce qui est dit dans la doc, c'est à dire créer un fichier en
mode écriture. Si un autre existait avant au même endroit et avec le
même nom, ben dommage pour lui., les données sont perdues. Encore une
fois, le C, c'est pas un langage de débutant. Si on lit bien la doc,
on voit que pour modifier un fichier existant, on peut l'ouvrir en
mode 'ajout' (append), c'est à dire "a'" ou "ab". Dans ce cas, il
n'est pas détruit, et les nouvelles données sont ajoutées en fin de
fichier.

Quand à "l'icône existe toujours", ben oui, le fichier n'a pas été
supprimé, c'est son contenu qui a été effacé.
Publicité
Poster une réponse
Anonyme