Si tu n'utilises pas les arguments, un void suffit.
f_in = fopen("in", "r");
Pense à vérifier si fopen a bien marché.
file = strdup("out1");
strdup est une extension GNU (je n'ai rien contre les extensions, c'est juste pour signaler qu'il y pourra y avoir des problèmes de portabilité par la suite).
Et vérifie aussi que la fonction a bien marché, sinon le fopen avec une valeur nulle causera un comportement indéfini.
Tu as oublié de comparer le début de buf avec "DEBUT". Et si une ligne du fichier d'entrée est plus longue que BUFSIZ, tu tronques les lignes...
De plus, si la ligne comprend un expace au plein milieu, ton fscanf ne prendra pas la fin de la ligne.
Tu pourrais rajouter le fclose dans ce block, pour éviter d'avoir un nombre indéterminé de fichiers ouverts en même temps (ça évite de planter si on ouvre trop de fichiers...).
Pour ton malloc: sizeof(char) vaut 1 par définition, donc tu peux simplifier l'écriture en
file = malloc(strlen("out") + cpt);
Pour la première étape, on a cpt == 1, donc tu réserves 4 caractères (car strlen("out") == 3). Or, tu places ensuite la chaîne "out", puis la chaîne de caractères représentant cpt+1 en décimal, c'est-à-dire "2". Tu aboutis donc à 5 caractères: 'o', 'u', 't', '2', '0円'.
Tu as donc effectué un débordement de tampon, et provoqué un comportement indéfini.
Mais, pour cpt > 1, ta formule marche efefctivement. Note quand même que faire le + cpt réserve plus de caractères qu'il n'en faut. Peut-être as-tu fait exprès, sachant que cpt caractères sont toujours suffisants pour afficher le nombre cpt+1 (si cpt > 1...), mais il faudrait au moins le metre en commentaire.
La ligne
file = malloc(strlen("out") + cpt + 1);
est donc suffisante; mais il ne faut pas oublier qu'on prend plus de place mémoire que nécessaire...
Par flemme, on va dire que la réécriture de ce code pour ne pas prendre plus de mémoire que nécessaire est laissé en exercice au lecteur ;)
Par ailleurs, il serait bon de vérifier que malloc n'a pas échoué, à moins de tenir à tester les comportements indéfinis de ton implémentation ;)
Et il faudrait aussi noter que le "32" pour le buffer du sprintf est purement arbitraire (très largement suffisant, mais juste pour noter en commentaire dans le code).
[^] # Re: ma solution
Posté par alf . En réponse au message Chaine de caractère. Évalué à 1.
Si tu n'utilises pas les arguments, un void suffit.
Pense à vérifier si fopen a bien marché.
strdup est une extension GNU (je n'ai rien contre les extensions, c'est juste pour signaler qu'il y pourra y avoir des problèmes de portabilité par la suite).
Et vérifie aussi que la fonction a bien marché, sinon le fopen avec une valeur nulle causera un comportement indéfini.
Idem: vérifier le succès de fopen
Tu as oublié de comparer le début de buf avec "DEBUT". Et si une ligne du fichier d'entrée est plus longue que BUFSIZ, tu tronques les lignes...
De plus, si la ligne comprend un expace au plein milieu, ton fscanf ne prendra pas la fin de la ligne.
Tu pourrais rajouter le fclose dans ce block, pour éviter d'avoir un nombre indéterminé de fichiers ouverts en même temps (ça évite de planter si on ouvre trop de fichiers...).
Pour ton malloc: sizeof(char) vaut 1 par définition, donc tu peux simplifier l'écriture en
Pour la première étape, on a cpt == 1, donc tu réserves 4 caractères (car strlen("out") == 3). Or, tu places ensuite la chaîne "out", puis la chaîne de caractères représentant cpt+1 en décimal, c'est-à-dire "2". Tu aboutis donc à 5 caractères: 'o', 'u', 't', '2', '0円'.
Tu as donc effectué un débordement de tampon, et provoqué un comportement indéfini.
Mais, pour cpt > 1, ta formule marche efefctivement. Note quand même que faire le + cpt réserve plus de caractères qu'il n'en faut. Peut-être as-tu fait exprès, sachant que cpt caractères sont toujours suffisants pour afficher le nombre cpt+1 (si cpt > 1...), mais il faudrait au moins le metre en commentaire.
La ligne est donc suffisante; mais il ne faut pas oublier qu'on prend plus de place mémoire que nécessaire...
Par flemme, on va dire que la réécriture de ce code pour ne pas prendre plus de mémoire que nécessaire est laissé en exercice au lecteur ;)
Par ailleurs, il serait bon de vérifier que malloc n'a pas échoué, à moins de tenir à tester les comportements indéfinis de ton implémentation ;)
Et il faudrait aussi noter que le "32" pour le buffer du sprintf est purement arbitraire (très largement suffisant, mais juste pour noter en commentaire dans le code).