sprintf et taille de buffer

Je souhaire écrire une fonction qui crée un fichier de log dont le nom serait : <nom du programme><date systeme>.log, la date devant être sous le format ddmmaaaa.

J'utilise pour cela un buffer et la fonction sprintf.

Code:

---

1 2 3 4 5 6

//Déclaration du buffer char logName[21];   sprintf(logName,"ExpMicros%.2d%.2d%.4d.log",tb->tm_mday,(tb->tm_mon)+1,(tb->tm_year)+1900); printf("logName: %s %d", logName,strlen(logName));

---

Le nom de mon fichier de log a toujours une taille de 21, c'est la raison pour laquelle mon buffer est à 21. Mais, ce qui est étrange c'est que lorsque je déclare mon buffer par char logName[1] ou n'importe quelle valeur en dessous de 21, mon programme ne plante pas et fonctionne parfaitement... alors que d'après ce que j'ai pu lire partout il fallait s'assurer que le buffer soit d'une taille suffisante sous peine de plantage... mais je n'ai aucun plantage !

Je précise que strlen(logName) me renvoie bien 21 malgré l'éventuel char logName[1];

Si quelqu'un pouvait m'expliquer ce mystère...

Juste parce que cela ne plante pas ne veut pas dire que ton programme est juste.

C'est en mettant une taille plus petite que tu risque un jour d'avoir un problème et tu y passeras des heures pour retrouver l'endroit où tu as mis une taille trop petite.

D'ailleurs, je te conseille de passer à une taille plus grande que juste le strict minimum. Il suffit que tu veuille ajouter une lettre devant ton nom et tu risqueras un plantage qui sera aussi compliqué à comprendre.

Jc

De plus, même si ta chaîne fait 21, il ne faut pas oublier un char en plus pour le zéro de fin de chaîne !

Citation:

---

Envoyé par koktel_dfr

Si quelqu'un pouvait m'expliquer ce mystère...

---

Cela peut très bien passer sur un système mais pas sur un autre ... comportement indéterminé !?

D'ailleurs, si le nom de ton fichier de log a toujours une taille de 21 (comme retourné par la fonction strlen()), la taille de ton buffer doit au minimum être de 22 caractères de manière à pouvoir contenir le caractère nul de fin de chaîne.

EDIT: grillé

Thierry

Citation:

---

Envoyé par koktel_dfr

. Mais, ce qui est étrange c'est que lorsque je déclare mon buffer par char logName[1] ou n'importe quelle valeur en dessous de 21, mon programme ne plante pas et fonctionne parfaitement... alors que d'après ce que j'ai pu lire partout il fallait s'assurer que le buffer soit d'une taille suffisante sous peine de plantage... mais je n'ai aucun plantage !

Je précise que strlen(logName) me renvoie bien 21 malgré l'éventuel char logName[1];

Si quelqu'un pouvait m'expliquer ce mystère...

---

C'est absolument normal..... Le printf écrit ses 22 caractères à partir de l'adresse initiale. N'ayant pas déclaré la bonne longueur, il écrit au delà de ce qui a été reservé.

Par conséquent, si c'est la dernière instruction du programme, ça ne porte pas à conséquence.

Par contre, dans quasiment tous les autres cas, si tu as d'autres variables, si c'est une fonction, si tu as un tableau ou une variable décalrée après la déclaration de la chaîne (sur la pile), etc.... ce sera écrasé....

Par exemple, si tu déclarais :

Code:

---

1 2 3

char Nom[10] ; char Ligne[20] ;

---

Et que tu commences à remplir Ligne, il est fort probable que Ligne serait écrasée lors du remplissage de Nom. Et si ce n'était pas le cas, quelque chose quelque part serait écrasée (ce qui serait situé dans le segment mémoire où le programme est loadé à l'adresse Nom+10).

ok, merci pour vos réponses, je comprends mieux maintenant.
Il me faut donc un buffer de 21+1 pour éviter tout problèmes éventuels, même si je n'en ai pas pour le moment...

Autre question mais totalement liée a celle-ci... le taille du nom de mon fichier de log sera toujours fixe quoi qu'il advienne, soit 21 caractère. Mais il n'en sera pas de même pour les lignes de mon log qui elles varierons en taille en fonction de l'erreur constaté (et qui sera écrite dans le fichier de log...).

Voici le code concernant l'écriture des lignes de mon log :

Code:

---

1 2 3 4 5 6 7 8 9

FILE *f_out; char logLine[200];   sprintf(logLine,"[ERROR] %s ---> %s - %s\n",functionName, errorDescription,error);   f_out = fopen(logFile,"a"); fputs(logLine, f_out); fclose(f_out);

---

Je trouve plutot dommage de devoir déclarer un buffer de taille 200 sachant que ma ligne de log peut ne pas dépasser les 50... aurait-il un moyen de gérer ca dynamiquement. Déterminer la taille de la ligne est facile avec strlen(), mais que mettre au niveau de la déclaration de logLine ?

Merci.

Si tu as la possibilité de retrouver la taille totale de la chaîne à mettre dans ton fichier avant sa construction avec sprintf, oui tu peux sans problème faire une allocation dynamique:

Code:

---

1 2 3 4 5 6 7

char * logLine = malloc (taille_de_la_chaine + 1);   if (logLine != NULL) { ... } ...

---

Sans oublier alors dans ce cas de libérer le buffer une fois que tu n'en as plus besoin ;)

Citation:

---

Envoyé par koktel_dfr

Je trouve plutot dommage de devoir déclarer un buffer de taille 200 sachant que ma ligne de log peut ne pas dépasser les 50... aurait-il un moyen de gérer ca dynamiquement. Déterminer la taille de la ligne est facile avec strlen(), mais que mettre au niveau de la déclaration de logLine ?

Merci.

---

Tu as plusieurs manières de faire.

En voici 1 totalement dynamique :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

FILE *f_out=NULL; char *logLine=NULL;   logLine = malloc ( (strlen(functionName) + strlen(errorDescription) + strlen(error) + 19 + 1 ); /* le 19 est pour les blancs plus [ERROR] + la fleche + le \n qui peut être CR LF ou CR */ if ( logLine != NULL ) { sprintf(logLine,"[ERROR] %s ---> %s - %s\n",functionName, errorDescription,error);   f_out = fopen(logFile,"a"); if ( f_out != NULL ) { fputs(logLine, f_out); fclose(f_out); } else fprintf(stderr,"%s",logLine); free(logLine); } else fprintf(stderr,"[ERROR] %s ---> %s - %s\n",functionName, errorDescription,error);

---

He bien merci à tout les deux, rapides en plus ;)

Vous me faites gagner de précieuses heures de travail, je teste ca tout de suite et je vous tiens au courant.

Ton code fonctionne parfaitement souviron34.

De plus, merci d'avoir tout deux précisé pour le test du retour de la fonction malloc()... je n'y aurait même pas pensé... même si je pense que, sauf erreur de ma part il doit être plutot rare qu'un malloc() ne puisse pas se faire.

Par contre tant que j'y suis j'ai une dernière question, c'est juste un détail, je me permet donc de la poser ici plutot que d'ouvrir un autre topic...

Je suis sous Windows(oui je sais, la honte...), lorsque j'ouvre mon fichier de log, généré avec le précédent code à l'aide du (au combien fabuleux...) bloc-note j'ai droit a un espèce de carré plutot qu'a un retour a la ligne... alors que lorsque je l'ouvre dans context(l'editeur de code que j'utilise) je n'ai aucun problème. A quoi cela est-il du et peut on corriger cela au niveau du code ?

Promis, après ca je ne vous embête plus :D

Citation:

---

Envoyé par koktel_dfr

Ton code fonctionne parfaitement souviron34.

De plus, merci d'avoir tout deux précisé pour le test du retour de la fonction malloc()... je n'y aurait même pas pensé... même si je pense que, sauf erreur de ma part il doit être plutot rare qu'un malloc() ne puisse pas se faire.

---

C'est vrai cela doit être rare de nos jours, ce que je n'est d'ailleurs encore jamais vu mais il est préférable de faire un test systématique du retour de ce genre de fonctions et des autres comme fopen par exemple, etc...

Citation:

---

Envoyé par koktel_dfr

Je suis sous Windows(oui je sais, la honte...)

---

Bin nan pas de honte, moi même j'était sous Windows de 3.1 à XP ... et j'en ai jamais eu honte même si maintenant je préfère l'utilisation de Linux depuis plus d'1 an (définitivement ;))

Citation:

---

Envoyé par koktel_dfr

lorsque j'ouvre mon fichier de log, généré avec le précédent code à l'aide du (au combien fabuleux...) bloc-note j'ai droit a un espèce de carré plutot qu'a un retour a la ligne... alors que lorsque je l'ouvre dans context(l'editeur de code que j'utilise) je n'ai aucun problème. A quoi cela est-il du et peut on corriger cela au niveau du code ?

---

Cela est peut-être dû au retour à la ligne mal interprété par le Bloc note... va savoir mais en générale il s'agit d'un problème d'encodage plus qu'autre chose, tout comme le passage de certains Linux vers Windows :lol:

Essaye peut-être avec:

Code:

---

fprintf (f_out, "%s\n", logLine);

---

Citation:

---

Envoyé par koktel_dfr

Promis, après ca je ne vous embête plus :D

---

On est là pour aider alors bon ....

Citation:

---

Envoyé par koktel_dfr

Je suis sous Windows(oui je sais, la honte...), lorsque j'ouvre mon fichier de log, généré avec le précédent code à l'aide du (au combien fabuleux...) bloc-note j'ai droit a un espèce de carré plutot qu'a un retour a la ligne... alors que lorsque je l'ouvre dans context(l'editeur de code que j'utilise) je n'ai aucun problème. A quoi cela est-il du et peut on corriger cela au niveau du code ?

Promis, après ca je ne vous embête plus :D

---

Tu peux l'ouvrir avec WordPad, ça devrait marcher... Le bloc-note ne prend pas en compte les retours "unix/like" CR/LF, ou l'inverse je sais plus, enfin bref il ne lit pas correctement les retours à la ligne :aie:

Je n'arrive toujours pas à régler ce satané problème d'ouverture avec le bloc-note...

Citation:

---

Envoyé par souviron34

Tu peux l'ouvrir avec WordPad, ça devrait marcher... Le bloc-note ne prend pas en compte les retours "unix/like" CR/LF, ou l'inverse je sais plus, enfin bref il ne lit pas correctement les retours à la ligne :aie:

---

Oui je sais bien, mais malheureusement je ne serait pas le seul à utiliser ce programme et la plupart du temps je pense que les personnes sous windows ont tendance à utiliser le bloc note pour ouvrir les fichiers textes. Ce n'est pas dramatique mais plutot embêtant car avoir tout le log sur une seule ligne ce n'est pas hyper lisible... et même en activant le retour a la ligne automatique sur le bloc note celui ci ne tient pas compte des /n et fait son retour à la ligne quand ca lui chante...

Je vais voir ca chez mon ami google si il peut me renseigner, sinon j'ouvrirai un topic, je ne pense pas être le seul à avoir déjà rencontré ce problème, enfin, j'espère !

En tout cas, encore merci à vous deux ;)

et si tu remplaces \n par \r ça marche ?

C'est anormal : Un fichier ouvert en écriture en mode texte sous Windows possède des fins de ligne à la Windows.
Il faudrait qu'il soit ouvert en écriture ne mode binaire pour que ces fins de ligne soient incompatibles...

Citation:

---

Envoyé par Médinoc

C'est anormal : Un fichier ouvert en écriture en mode texte sous Windows possède des fins de ligne à la Windows.
Il faudrait qu'il soit ouvert en écriture ne mode binaire pour que ces fins de ligne soient incompatibles...

---

Je confirme. Si cependant par bizarrerie tel n'est pas le cas, alors je pense qu'utiliser "\r\n" au lieu de "\n" devrait résoudre le problème.

Mon fichier est bien ouvert en mode texte...

Code:

---

1 2	f_out = fopen(logFile,"a");

---

Mais bon, le problème est réglé puisque un \r\n l'a résolu !
Donc merci ! maintenant si quelqu'un a une explication je suis preneur...

Pour les éventuels sceptiques qui liraient mon code j'ai laissé un beau commentaire :

Code:

---

1 2 3 4 5 6

// L'option \r\n permet d'avoir un affichage correct des retours à la ligne sous // le bloc-note windows. // Sans le \r précédent le \n les retours à la ligne sont remplacés par des // caractères cunéiformes venus de je ne sais trop quelle contrée lointaine // ignorée de tous...

---

ca devrait aller :lol:

Quel est le compilateur utilisé?

Citation:

---

Envoyé par stephl

Quel est le compilateur utilisé?

---

J'utilise GCC sous Windows par l'intermédiaire de Cygwin

Citation:

---

Envoyé par koktel_dfr

J'utilise GCC sous Windows par l'intermédiaire de Cygwin

---

Si j'ai bonne mémoire, cygwin émule (ou quelque chose dans le genre) Linux. Je pense que les librairies fournies utilisent donc le format UNIX pour les fins de ligne. D'où le problème. Peut-être vaut-il mieux utiliser gcc mingw?

Citation:

---

Envoyé par stephl

Si j'ai bonne mémoire, cygwin émule (ou quelque chose dans le genre) Linux. Je pense que les librairies fournies utilisent donc le format UNIX pour les fins de ligne. D'où le problème. Peut-être vaut-il mieux utiliser gcc mingw?

---

Le truc c'est que je voudrais que mon code sois portable sous UNIX, c'est justement pour ca que j'utilise GCC sous windows. Enfin, au pire si il n'y a qu'un caractere de fin de ligne a changer ce n'est pas bien grave.

Citation:

---

Envoyé par koktel_dfr

Le truc c'est que je voudrais que mon code sois portable sous UNIX, c'est justement pour ca que j'utilise GCC sous windows. Enfin, au pire si il n'y a qu'un caractere de fin de ligne a changer ce n'est pas bien grave.

---

ben si tu laisses le \r ça sera portable....

Pour mémoire, le \r ramène le curseur en début de ligne. Vu que le \n fait normalement CR et LF, ça ne changera rien..

;)

Sur les implémentations Windows des bibliothèques, "\n" est traduit en CR+LF lors d'une écriture de fichier, et réciproquement en lecture CR+LF est traduit en "\n".
Il n'y a pas à proprement parler de problème de portabilité là. De toute façon, seul le source sera portable. Il faudra le compiler une fois sous UNIX et une fois sous Windows. Dans le source doit figurer "\n" pour effectuer un passage à la ligne suivante. C'est au rôle de la bibliothèque d'effectuer les traductions éventuelles.

Citation:

---

Envoyé par stephl

Sur les implémentations Windows des bibliothèques, "\n" est traduit en CR+LF lors d'une écriture de fichier, et réciproquement en lecture CR+LF est traduit en "\n".
Il n'y a pas à proprement parler de problème de portabilité là. De toute façon, seul le source sera portable. Il faudra le compiler une fois sous UNIX et une fois sous Windows. Dans le source doit figurer "\n" pour effectuer un passage à la ligne suivante. C'est au rôle de la bibliothèque d'effectuer les traductions éventuelles.

---

non je suppose que ce qu'il voulait dire c'est pour que le fichier résultant soit portable (et éventiellement le prgramme, mais comme tu dis faudra le recompiler)

Citation:

---

Envoyé par souviron34

non je suppose que ce qu'il voulait dire c'est pour que le fichier résultant soit portable (et éventiellement le prgramme, mais comme tu dis faudra le recompiler)

---

Le message disait:

Citation:

---

je voudrais que mon code sois portable sous UNIX

---

Mais s'il s'agit de la portabilité du fichier résultant, je suis d'accord avec vous: le problème se posera et il faudra faire un choix.

Citation:

---

Envoyé par souviron34

non je suppose que ce qu'il voulait dire c'est pour que le fichier résultant soit portable (et éventiellement le prgramme, mais comme tu dis faudra le recompiler)

---

Effectivement je souhaiterais que les deux soient portable, maitenant un fichier texte est un fichier texte, peut importe qu'il soit sous windows ou unix. Enfin, quoique c'est ce que je pensais...mais a mon avis c'est plus un problème de bloc notes car comme je l'ai dit plus haut mon fichier texte se lit sans problème sous context même sans le \r.

Je sais bien qu'il faudra le recompiler mais au moins je n'aurais pas à écrire deux fois le programme, une fois sous windows et une fois sous unix.

Portable ou non, il faudra recompiler de toute façon...

Et sous UNIX, écrire \r\n donnera des fichiers qui ne seront pas correctement affichés par les éditeurs de texte les plus basiques d'unix (vi affichera ^M à la fin de chaque ligne). Par contre, ils seront correctement affichés par le bloc-note.

Donc, le gcc à utiliser sous Windows n'est pas celui de Gygwin, mais MinGW.

Citation:

---

Envoyé par souviron34

non je suppose que ce qu'il voulait dire c'est pour que le fichier résultant soit portable (et éventiellement le prgramme, mais comme tu dis faudra le recompiler)

---

En ce qui concerne la portabilité du fichier, le mieux est à mon avis de passer par un utilitaire tel que dos2unix/unix2dos ou quelque chose du genre qui s'occupe de la convertion des fichiers. C'est ce que je fais, et je laisse ensuite le runtime du C gérer la lecture et l'écriture des caractères de fin de ligne de manière transparente.

Thierry

Citation:

---

Envoyé par koktel_dfr

Voici le code concernant l'écriture des lignes de mon log :

Code:

---

1 2 3 4 5 6 7 8 9

FILE *f_out; char logLine[200];   sprintf(logLine,"[ERROR] %s ---> %s - %s\n",functionName, errorDescription,error);   f_out = fopen(logFile,"a"); fputs(logLine, f_out); fclose(f_out);

---

Je trouve plutot dommage de devoir déclarer un buffer de taille 200 sachant que ma ligne de log peut ne pas dépasser les 50... aurait-il un moyen de gérer ca dynamiquement. Déterminer la taille de la ligne est facile avec strlen(), mais que mettre au niveau de la déclaration de logLine ?

Merci.

---

Sans revenir sur les remarques pertinentes et les corrections qu'ont deja fournit d'autre posteurs, quel est l'interet de la chaine temporaire ? Si tu ne l'utilises pas en dehors de cet extrait, le code suivant

Code:

---

1 2 3 4 5 6 7 8

FILE *f_out; f_out = fopen(logFile,"a"); if(f_out != NULL) { fprintf(f_out, "[ERROR] %s ---> %s - %s\n", functionName, errorDescription,error); fclose(f_out); }

---

est bien plus simple.

+10

On est vraiment c.ns de pas y avoir pensé plus tôt :oops: :oops:

MAis bon, on regardait pas ça.. Mais quand même..

Bravo :hola: