donc ça lit le fichier source "file.c" et ça écrit dans le fichier destination "file2.c".
Donc ce code fait n'importe quoi.
mais, au runtime j'ai droit à une "segmentation fault" dont je ne vois pas la raison...
C'est un jeu des 1000 erreurs ?
pas du tout, pas évident, pour moi, à voir toutes erreurs...
notes que j'ai vu pire dans un tuto... -- une bévue
Pierre Maurette
[...]
return EXIT_FAILURE;
Si le premier fichier n'existe pas mais le second existe, alors on a ouvert le second, mais on ne l'a pas fermé. Mauvais.
Non. La norme est claire. Contrairement à la désallocation de la mémoire, les streams sont fermés à la sortie normale du programme: §7.20.4.3.4 (concerne exit()): "Next, all open streams with unwritten buffered data are flushed, all open streams are closed, and all files created by the tmpfile function are removed."
Et la norme ramène à exit(int) le return int et l'atteinte du } dans main().
[...]
printf("Error: can't create file for writing.n"); return 1;
return EXIT_FAILURE;
Il faudrait fermer là le premier fichier au lieu de le laissé ouvert
Non non. Voir plus haut.
-- Pierre Maurette
[...]
return EXIT_FAILURE;
Si le premier fichier n'existe pas mais le second existe, alors on a ouvert
le second, mais on ne l'a pas fermé. Mauvais.
Non.
La norme est claire. Contrairement à la désallocation de la mémoire,
les streams sont fermés à la sortie normale du programme:
§7.20.4.3.4 (concerne exit()):
"Next, all open streams with unwritten buffered data are flushed, all
open streams are closed, and all files created by the tmpfile function
are removed."
Et la norme ramène à exit(int) le return int et l'atteinte du } dans
main().
[...]
printf("Error: can't create file for writing.n");
return 1;
return EXIT_FAILURE;
Il faudrait fermer là le premier fichier au lieu de le laissé ouvert
Si le premier fichier n'existe pas mais le second existe, alors on a ouvert le second, mais on ne l'a pas fermé. Mauvais.
Non. La norme est claire. Contrairement à la désallocation de la mémoire, les streams sont fermés à la sortie normale du programme: §7.20.4.3.4 (concerne exit()): "Next, all open streams with unwritten buffered data are flushed, all open streams are closed, and all files created by the tmpfile function are removed."
Et la norme ramène à exit(int) le return int et l'atteinte du } dans main().
[...]
printf("Error: can't create file for writing.n"); return 1;
return EXIT_FAILURE;
Il faudrait fermer là le premier fichier au lieu de le laissé ouvert
Non non. Voir plus haut.
-- Pierre Maurette
Eric Levenez
Le 17/09/06 18:09, dans , « Pierre Maurette » a écrit :
Si le premier fichier n'existe pas mais le second existe, alors on a ouvert le second, mais on ne l'a pas fermé. Mauvais.
Non. La norme est claire.
Oui, je sais très bien tout cela. Je n'ai pas dit que ce n'était pas conforme, juste que c'était mauvais. Il faut apprendre à fermer ce que l'on a ouvert. Et ce que l'auteur de l'immonde code à fait dans main, il le fait aussi dans toute autre fonction. Je le répète : c'est mauvais.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Le 17/09/06 18:09, dans <mn.8c417d69925ba558.31483@laposte.net>, « Pierre
Maurette » <maurettepierre@wanadoo.fr> a écrit :
Si le premier fichier n'existe pas mais le second existe, alors on a ouvert
le second, mais on ne l'a pas fermé. Mauvais.
Non.
La norme est claire.
Oui, je sais très bien tout cela. Je n'ai pas dit que ce n'était pas
conforme, juste que c'était mauvais. Il faut apprendre à fermer ce que l'on
a ouvert. Et ce que l'auteur de l'immonde code à fait dans main, il le fait
aussi dans toute autre fonction. Je le répète : c'est mauvais.
--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.
Le 17/09/06 18:09, dans , « Pierre Maurette » a écrit :
Si le premier fichier n'existe pas mais le second existe, alors on a ouvert le second, mais on ne l'a pas fermé. Mauvais.
Non. La norme est claire.
Oui, je sais très bien tout cela. Je n'ai pas dit que ce n'était pas conforme, juste que c'était mauvais. Il faut apprendre à fermer ce que l'on a ouvert. Et ce que l'auteur de l'immonde code à fait dans main, il le fait aussi dans toute autre fonction. Je le répète : c'est mauvais.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Eric Levenez
Le 17/09/06 16:18, dans <1hltgrc.1j328871aptwh5N%, « Une bévue » a écrit :
Eric Levenez wrote:
Mais faut pas lire des choses comme cela !
beuh, comme je le sais "a priori" ???
Tu regardes la façon dont le main est déclaré. Normalement cela donne tout de suite le niveau du mec. Après tu regardes si les codes de retour des fonctions sont testés. Si ce n'est pas bon, tu vas sur un autre site.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Le 17/09/06 16:18, dans
<1hltgrc.1j328871aptwh5N%pere.noel@laponie.com.invalid>, « Une bévue »
<pere.noel@laponie.com.invalid> a écrit :
Eric Levenez <news@levenez.com> wrote:
Mais faut pas lire des choses comme cela !
beuh, comme je le sais "a priori" ???
Tu regardes la façon dont le main est déclaré. Normalement cela donne tout
de suite le niveau du mec. Après tu regardes si les codes de retour des
fonctions sont testés. Si ce n'est pas bon, tu vas sur un autre site.
--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.
Le 17/09/06 16:18, dans <1hltgrc.1j328871aptwh5N%, « Une bévue » a écrit :
Eric Levenez wrote:
Mais faut pas lire des choses comme cela !
beuh, comme je le sais "a priori" ???
Tu regardes la façon dont le main est déclaré. Normalement cela donne tout de suite le niveau du mec. Après tu regardes si les codes de retour des fonctions sont testés. Si ce n'est pas bon, tu vas sur un autre site.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Eric Levenez
Le 17/09/06 16:18, dans <1hltgod.1sttcuc1p2wv17N%, « Une bévue » a écrit :
Eric Levenez wrote:
Ça corrige juste 1 erreur, il en reste 999 à trouver...
999 erreurs sur 35 lignes, l'auteur est un champion alors...
Ce genre de champion pullulent sur Internet. Normalement tout étudiant sur un langage donné, fera sa propre page web sur le sujet, truffée d'erreur, et considèrera que son tutorial est le meilleur au monde.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Le 17/09/06 16:18, dans
<1hltgod.1sttcuc1p2wv17N%pere.noel@laponie.com.invalid>, « Une bévue »
<pere.noel@laponie.com.invalid> a écrit :
Eric Levenez <news@levenez.com> wrote:
Ça corrige juste 1 erreur, il en reste 999 à trouver...
999 erreurs sur 35 lignes, l'auteur est un champion alors...
Ce genre de champion pullulent sur Internet. Normalement tout étudiant sur
un langage donné, fera sa propre page web sur le sujet, truffée d'erreur, et
considèrera que son tutorial est le meilleur au monde.
--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.
Le 17/09/06 16:18, dans <1hltgod.1sttcuc1p2wv17N%, « Une bévue » a écrit :
Eric Levenez wrote:
Ça corrige juste 1 erreur, il en reste 999 à trouver...
999 erreurs sur 35 lignes, l'auteur est un champion alors...
Ce genre de champion pullulent sur Internet. Normalement tout étudiant sur un langage donné, fera sa propre page web sur le sujet, truffée d'erreur, et considèrera que son tutorial est le meilleur au monde.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
pere.noel
Eric Levenez wrote:
Tu regardes la façon dont le main est déclaré. Normalement cela donne tout de suite le niveau du mec. Après tu regardes si les codes de retour des fonctions sont testés. Si ce n'est pas bon, tu vas sur un autre site.
ce qui était tout à fait le cas )))
ps j'ai trouvé une lib btree... dont celle de ruby en est inspirée... -- une bévue
Eric Levenez <news@levenez.com> wrote:
Tu regardes la façon dont le main est déclaré. Normalement cela donne tout
de suite le niveau du mec. Après tu regardes si les codes de retour des
fonctions sont testés. Si ce n'est pas bon, tu vas sur un autre site.
ce qui était tout à fait le cas )))
ps j'ai trouvé une lib btree...
dont celle de ruby en est inspirée...
--
une bévue
Tu regardes la façon dont le main est déclaré. Normalement cela donne tout de suite le niveau du mec. Après tu regardes si les codes de retour des fonctions sont testés. Si ce n'est pas bon, tu vas sur un autre site.
ce qui était tout à fait le cas )))
ps j'ai trouvé une lib btree... dont celle de ruby en est inspirée... -- une bévue