le printf magique

Bonjour,
voila j'ai un soucis avec mon code C. Le bout de code se lance parfaitement si on laisse le printf dans le code et si je l'enleve alors j'ai un problème lors de l'exécution.

voici le code

Code:

---

1 2 3 4 5 6 7

for(i=1;i<nbEtapes;i++){ a=b+dureeTotalTournee(distanceStruct(tableauEtapesFinal,i-1,i),0); b=a+10; //printf("%d\n%d \n",a,b);   creerLigneTournee(BD,(tableauEtapesFinal+i)->nom, (tableauEtapesFinal+i)->cp,(tableauEtapesFinal+i)->type,10,id_tournee,heure,a,b);

---

Le printf est mit en commentaire. je ne comprend pas l'erreur surtout que a et b sont bien renseignés.

Merci de votre aide.

à quel valeur de i cela plante, sur quelle ligne dureetotaltournee ou creerlignetournee ?

ce sont juste des questions te permettant de chercher à identifier plus précisément la cause du plantage, probablement aléatoire mais pas spécifique à printf car la magie n'existe pas.

bah tout est la.... lorsque je voulais savoir a quel indice cela plantait j'ai voulu mettre le printf et a ce moment la plus de plantage....

et lorsque je le retire cela plante des le debut donc à i=1..
étrange

ca plante à i=1 mais est-ce que la fonction dureeTotalTournee est executée complétement ou est-ce que cela plante à la fonction d'après cad creerLigneTournee

Oui la fonction duréetotale est bien réalisée car les entiers a et b sont renseignés. le problème vient donc de la méthode creerLigneTournée.
j'ai donc essayer de mettre directement dans la fonction des valeurs fixe de a et b telle que 23 et 23. Et j'ai lancé cela sans le printf et cela deconne toujours.. mais des que je remet le printf cela remarche.

Le problème venait d'une variable mal initialisé dans la fonction creerFeuilleRetrait. le problème c'est pourquoi cela marchait uniquement quand il y avait un printf auparavant? en quoi il est important ?

en rien tu ne devrais pas te focaliser dessus.

le seul lien est que printf utilise la pile et que les fonctions aussi.

Ok merci de ton aide. C'est vrai je me suis trop focalisé dessus et j'aurai du d'avantage regarder les fonctions au alentours.

Donc problème résolu.
Erreur fonction creerFeuilleRetrait où une variable etait mal initialisé.

Citation:

---

Envoyé par nicodn02

Le problème venait d'une variable mal initialisé dans la fonction creerFeuilleRetrait.

---

Ce qui entraine un comportement indéfini : tout peut arriver.

http://emmanuel-delahaye.developpez.com/notes.htm#ub

il faut se méfier de printf pour l'affichage de trace, sur ma plateforme xp mettre un % en début de chaîne génére un plantage à l'execution, printf("% quelque chose %d",4); par exemple et ce n'est pas forcément évidemment à voir avec un ici et l'autre là. une MACRO serait déja pas plus mal

Jue,

Citation:

---

Envoyé par hegros

il faut se méfier de printf pour l'affichage de trace, sur ma plateforme xp mettre un % en début de chaîne génére un plantage à l'execution, printf("% quelque chose %d",4); par exemple et ce n'est pas forcément évidemment à voir avec un ici et l'autre là. une MACRO serait déja pas plus mal

---

Si ce que tu cherches à afficher n'est pas conforme (ce qui est le cas de ton printf), une macro ne changera rien, je pense. :)

Citation:

---

Envoyé par droggo

Jue,

Si ce que tu cherches à afficher n'est pas conforme (ce qui est le cas de ton printf), une macro ne changera rien, je pense. :)

---

ce n'est pas le problème d'être conforme, de connaître les specs ou les bugs de cette fonction, c'est que c'est une erreur possible de taper un % dans un début de printf et que cela entraîne un plantage d'execution sur ma plateforme, je ne pense pas que j'utiliserais printf pour faire un trace pour la macro non plus.

Citation:

---

Envoyé par hegros

ce n'est pas le problème d'être conforme, de connaître les specs ou les bugs de cette fonction, c'est que c'est une erreur possible de taper un % dans un début de printf et que cela entraîne un plantage d'execution sur ma plateforme, je ne pense pas que j'utiliserais printf pour faire un trace pour la macro non plus.

---

Peux-tu montrer exactement le code qui fait planter ?

tout de suite chef !

Code:

---

1 2 3 4 5 6 7

#include <stdio.h>   int main(int argc,char*argv[]) { printf("%nombre argument %d\n\n\n",argc); return 0; }

---

il doit surement prendre le n de "nombre" avec le % comme spécificateur de format ce qui le fait planter je ne sais pas avec "fombre" je n'ai pas ce problème (cela affiche 0.0XF)

avec le message d'erreur

Salut,

Citation:

---

Envoyé par hegros

ce n'est pas le problème d'être conforme, de connaître les specs ou les bugs de cette fonction

---

Ce n'est pas un bug !

Les % sont interprété par printf(), et si tu veux afficher le caractères % il faut le doubler : %%.

D'après la page man de printf() le %n stocke le nombre de caractères déjà écrit dans le paramètre correspondant (quoi doit être de type int*).

Donc ici il tente d'écrire dans l'adresse représenté par la valeur de argc -> plantage logique !


printf() c'est puissant, du coup cela peut même être dangereux :aie:

a++

noooooon je ne veux pas afficher le % c'est juste une erreur de frappe.

ce n'est pas un bug en effet c'est une écriture dans les choux :marteau:

Mais alors je ne vois pas le problème : tu lui passes un format incorrect c'est normal qu'il plante !

a++

il n'y a pas de problème son interface n'est pas robuste cela plante parfois cela fais fonctionner des programmes autant réécrire une fonction qui corrige ces comportements indéfinis du coup cela me prendra 5fois moins de temps qu'apprendre la syntaxe de printf

Citation:

---

Envoyé par hegros

il n'y a pas de problème son interface n'est pas robuste cela plante parfois cela fais fonctionner des programmes autant réécrire une fonction qui corrige ces comportements indéfinis du coup cela me prendra 5fois moins de temps qu'apprendre la syntaxe de printf

---

Tu as invoqué le formateur "%n" sans fournir d'adresse de char. C'est une erreur de codage dont tu es seul responsable. Le comportement est indéterminé. Un compilateur bien réglé le voit tout de suite :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

Project : Forums Compiler : GNU GCC Compiler (called directly) Directory : C:\dev\forums\ -------------------------------------------------------------------------------- Switching to target: default Compiling: main.c main.c: In function `main': main.c:5: warning: format argument is not a pointer (arg 2) main.c:5: warning: too few arguments for format main.c: At top level: main.c:3: warning: unused parameter 'argv' Linking console executable: console.exe Process terminated with status 0 (0 minutes, 0 seconds) 0 errors, 3 warnings

---

ok printf n'a jamais eu de bug c'est la plus parfaite des fonctions d'affichage

je n'ai rien invoqué, le %n s'est retrouvé là par hasard, suite à une erreur de frappe un % s'est inséré avant la chaîne que je voulais afficher, effectivement cette commande attend l'adresse d'un int et je lui donne n'importe quoi et elle me sort n'importe quoi, normal

Code:

---

printf("%3d",argc);

---

en 2008 je pensais écrire la valeur de argc en 3d, j'étais loin, loin là bas dans la nuit noire et obscure...

Citation:

---

Envoyé par hegros

ok printf n'a jamais eu de bug c'est la plus parfaite des fonctions d'affichage

---

Je te sens légèrement ironique, là... A ma connaissance, printf() est sans risque si on l'utilise correctement. Ce n'est pas le cas de gets(), par exemple, qu'il est impossible de faire fonctionner sans risques et qui est véritablement un bug. Même scanf() peut être utilisé de manière plus sure que gets().

Citation:

---

je n'ai rien invoqué, le %n s'est retrouvé là par hasard, suite à une erreur de frappe un % s'est inséré avant la chaîne que je voulais afficher, effectivement cette commande attend l'adresse d'un int et je lui donne n'importe quoi et elle me sort n'importe quoi, normal

---

On a mis en évidence un bug du programmeur. Le langage C et sa bibliothèque ne sont pas en cause ici.

Citation:

---

Code:

---

printf("%3d",argc);

---

en 2008 je pensais écrire la valeur de argc en 3d, j'étais loin, loin là bas dans la nuit noire et obscure...

---

Comprends pas...

pour le moment aucune explication de plus de pourquoi avec un printf le programme du PO marche et sans cela ne marche pas

pour le moment c'est une variable non initialisée, printf perturbe positivement le comportement puisqu'il signale en quelque sorte un bug applicatif mais tout cela n'est pas dans la doc et c'est bien embêtant.

pour mon exemple de %n c'est un problème de débutant que j'ai rencontré car ce n'est pas du tout cette commande que je voulais utilisé ni même ne voulais afficher le caractère spécial %

soit des printf en vrac dans l'application en fonction de tracing ce n'est pas forcément une bonne idée...

Citation:

---

Envoyé par hegros

pour le moment aucune explication de plus de pourquoi avec un printf le programme du PO marche et sans cela ne marche pas

---

Le P.O. a donné l'explication :

Citation:

---

Envoyé par nicodn02

Le problème venait d'une variable mal initialisé dans la fonction creerFeuilleRetrait.

---

Ce à quoi j'ai évidemment répondu, comme tu l'aurais fait :

Citation:

---

Envoyé par -ed-

Ce qui entraine un comportement indéfini : tout peut arriver.

http://emmanuel-delahaye.developpez.com/notes.htm#ub

---

Il n'est pas inutile de lire les réponses, ça évite de tourner en rond...

Citation:

---

pour le moment c'est une variable non initialisée, printf perturbe positivement le comportement puisqu'il signale en quelque sorte un bug applicatif mais tout cela n'est pas dans la doc et c'est bien embêtant.

---

Revois d'urgence la notion de comportement indéfini (UB). Ce n'est pas printf() qui est en cause, c'est le UB qui entraine n'importe quoi. A partir du moment où un UB s'est produit, plus rien ne fonctionne normalement, mais de façon imprévisible, par définition.

Citation:

---

soit des printf en vrac dans l'application en fonction de tracing ce n'est pas forcément une bonne idée...

---

Tu n'as pas démontré pourquoi.

- Ton exemple personnel montre qu'un UB fait n'importe quoi
- Celui du P.O. aussi

Ce que tu as démontré, c'est qu'il ne faut pas qu'il y ait de UB dans un programme, mais ça, on le savait déjà, et de plus, ça n'a aucun rapport avec printf().

Bref, je ne vais pas tarder à nettoyer ce post...

focus

ce n'est pas une démonstration...ce qui m'intéresse c'est l'usage qu'il en faisait parce que sinon il n'y a pas de raison qu'une variable non initialisée provoque un UB par sa propre déclaration

En tout cas aucune magie dedans.

ciaos bye

Citation:

---

Envoyé par hegros

il n'y a pas de raison qu'une variable non initialisée provoque un UB par sa propre déclaration

---

Si tu écrit dans un pointeur non-initialisé tu écris n'importe où en mémoire, et tu obtiens un comportement indéfini :

• Si tu as de la chance ca plante (ce qui t'oblige à rechercher l'origine du bug).
• Si tu n'as pas de chance le programme semble se dérouler correctement, mais le bug peut ressurgir n'importe quand (et lorsque le bug ressurgit des mois plus tard lorsqu'on modifie une toute autre partie du programme c'est vraiment affreux à débugger...)

Le simple fait de modifier une ligne de ton programme, ou même de le recompiler avec un compilateur différent peut faire resurgir le bug. La présence du printf() masquait le bug justement à cause de ce comportement indéfini... mais printf() n'était nullement en cause ;)

a++

Citation:

---

Envoyé par adiGuba

Si tu écrit dans un pointeur non-initialisé tu écris n'importe où en mémoire, et tu obtiens un comportement indéfini :

• Si tu as de la chance ca plante (ce qui t'oblige à rechercher l'origine du bug).
• Si tu n'as pas de chance le programme semble se dérouler correctement, mais le bug peut ressurgir n'importe quand (et lorsque le bug ressurgit des mois plus tard lorsqu'on modifie une toute autre partie du programme c'est vraiment affreux à débugger...)

Le simple fait de modifier une ligne de ton programme, ou même de le recompiler avec un compilateur différent peut faire resurgir le bug. La présence du printf() masquait le bug justement à cause de ce comportement indéfini... mais printf() n'était nullement en cause ;)

a++

---

mais toi tu es encore sur mon exemple alors que j'ai vu mon erreur (%n attends un int*), la citation que tu mets est en rapport avec le bug du PO(sa variable non initialisé n'est pas la mienne) et c'est celui là auquel je faisais maintenant allusion

comme tu dis il y a de grandes chances que se soit une écriture, affectation dans une variable non initialisé (pas forcément pointeur d'ailleurs?)

@+++