J'ai un souci avec strcpy, et je ne comprend vraiment pas d'ou ca vient...
En fait, il écrit dans une autre variable qui n'a rien à voir (code[0][0] pour être précis)
Enfin, je met le code sur le wall, si quelqu'un veut bien jeter un (ou 2) oeil, je l'en remercie.



Wall (129) : Afficher le code source - Ouvrir dans une nouvelle fenêtre

Honnettement, je te proposes de revoir ta copie ! J'ai énormément d'erreur :
- es tu sur qu'il faille utilisé '\\n', '\\t' etc ? Ne serait-ce pas plutot '\n' et '\t' ?
- déclarer un pointeur ne l'initialise pas à NULL. Donc quand tu fais un

if (pointeur) free(pointeur)

, et que ta variable pointeur n'est pas initialisée, cela ne sert à rien et j'avoue ne pas connaitre le comportement de la fonction free dans ce cas (sans doute dépendant de l'implémentation)
- certaines variables sont utilisées sans être initialisées. Lorsque tu lis la première ligne, n'oublie pas d'initialiser x à 0
- tu alloues tes buffer ligne et ligne2 à 100octets. Très bien. Mais rien ne dit que la ligne que tu lira avec ta fonction lireLigne ne fera pas 1234 octets ==> buffer overflow

Bref, des petites choses à revoir, et la modification d'une variable qui ne devrait pas être modifiées est généralement symptomatique d'un buffer overflow...

Et si tu compiles avec Visual Studio C++, essai avec un autre compilateur pour trouver les problèmes de variables non initialiées. Je dis ça, car, de mémoire, Visual Studio initialise toutes les variables, en mode debug tout du moins...

le couple GCC (compilateur GNU) & GDB (déboggueur GNU) est l'ami du développeur, avec ça tu pourras voir par toi même ce que fait ton code (c'est aussi une excellente façon d'apprendre).

tu compiles avec:
g++ -o mon_binaire -g -O0 MES_OPTIONS MES_LIBRAIRIES mes_fichiers.cpp

tu compiles avec -g pour pouvoir débogguer et -O0 pour que le code généré corresponde strictement au code (ça enlève les optimisations pour que GDB puisse faire le lien entre le binaire et le code source).

pour débogguer:
gdb
(gdb) file mon_binaire
(gdb) run
...
(gdb) quit pour quitter
(gdb) help t'affiche tout ce que tu veux savoir
(gdb) bt affiche la pile (après un crash)
(gdb) up remonte la pile
(gdb) printf "%s %d %...", paramètres <- affiche la valeur des variables/expressions lancées dans l'environnement de ton programme même planté!!

avec ça tu devrais voir tout seul pourquoi ça plante.

Un proverbe chinois dit:
donne un poisson à un homme il mangera un soir, apprend lui à pêcher il mangera tous les jours.

Ahh zuzuf, si tu penses vraiment que je n'ai pas cherché...
Pour ce qui est du compilo, non, je n'utilise pas celui visual, mais minGW (EDI=Code block) et j'utilise bel et bien gdb...

Je n'avait par contre pas pensé au buffer overflow, je le reconnais ...

Quand aux '\\n', je crains qu'il ne s'agisse d'un bug du wall, car je ne suis pas idiot à ce point (pour etre honnête, je doute même qu'un tel code compile, car les ' précisent qu'il ne doit s'agir que d'un seul caractère).

Sinon, (je sais, les var globales, c'est crade) les variables globales sont init à 0, normallement, non?

Je n'avais pas vu que j'avais oublié d'init le x erreur d'inatention, j'étais persuadé de l'avoir fait...

Pour le malloc(100), j'avoue que c'est assez dégueulasse comme code, mais la 1ère ligne étant de taille fixe, ça n'aurait été (si je n'avait pas eu besoin de poster ça) un problème que lorsque les fichiers d'entrées auraient changés ou le code adapté pour gérer plus de trucs...

Enfin, je vous remercie, je vais continuer à chercher

Ah oui, un petit problème de wall, c'est fort possible pour les \\ !
Pour les variables globales, sauf si c'est annoncer dans la norme, rien ne les obligent à être initialisée. Et puis c'est une bonne habitude à prendre je pense...

Surtout qu'en essayant ton code, au début, tout plantait car x n'était pas initialisé ! Il a fallu que je l'initialise moi-même pour finalement avoir une erreur d'execution plus loin.

Ensuite, si tes fichiers ont une structure précise qui justifie un malloc(100), pourquoi pas. Mais alors n'oublie pas de mettre un petit commentaire dans le code source. Car quand tu reprendras ton code, tu te diras "mais pourquoi j'ai fait un truc aussi crade "

Ne trouvant pas l'origine de ce BoF, j'ai appliqué la solution probablement la plus crade...
J'ai simplement augmenté de 1 la taille de chaque chaine de code ^^ mais si quelqu'un à l'explication, je suis preneur malgré tout.