Discussion :

[koktel_dfr]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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...

[fearyourself]

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

[Franck.H]

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 !

[Franck.H]

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é !?

[Thierry Chappuis]

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

[souviron34]

. 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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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).

[koktel_dfr]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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.

[Franck.H]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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

[souviron34]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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);

[koktel_dfr]

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.

[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.

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

[Franck.H]

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...

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 )

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

Essaye peut-être avec:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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

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

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

[souviron34]

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

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

[koktel_dfr]

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

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

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

[souviron34]

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

[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...

[stephl]

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.

[koktel_dfr]

Mon fichier est bien ouvert en mode texte...

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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

[stephl]

Quel est le compilateur utilisé?

[koktel_dfr]

Quel est le compilateur utilisé?

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