Discussion :

[Emmanuel Delahaye]

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

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.

Code :

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

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

[hegros]

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

[Emmanuel Delahaye]

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 :

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 :

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

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.

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

[hegros]

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

[adiGuba]

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

[hegros]

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

@+++