Logo GNT
Actualités Tests & Guides Bons Plans
GTA 6 iPhone 17 Copilot Switch 2 Temu ChatGPT Tesla
OVH Cloud OVH Cloud
Entraide Développement Développement Langage C++ Bug indétectable via printf() / cout

Bug indétectable via printf() / cout

148 réponses
Avatar
AG
Bonjour =E0 tous,

Je travaille dans une =E9quipe de personnes pour lesquels le d=E9bugger
n'est pas l'outil qui tombe sous le sens lorsqu'il s'agit de trouver
les bugs des outils qu'ils ont d=E9velopp=E9.

Afin de les sensibiliser, je recherche un exemple de bug difficile
(voir impossible) a d=E9tecter via des printf()/cout qui n'afficheraient
que les contenus des variables. (Je me rends bien compte qu'on doit
pouvoir tout d=E9bugger avec printf()/cout, mais il faut parfois
afficher les adresses des variable (en plus de leur valeur), voir
parfois la m=E9moire =E0 certains endroits.)

Je voudrais construire un exemple simple (notions de C++ pas trop
compliqu=E9es) et court (un seul fichier, 100 lignes max) pour qu'on
puisse l'=E9tudier en un quart d'heure, mais le d=E9bugger en un temps
presque infini sans d=E9bugger.

Il est possible que l'exemple, puisqu'il y a un bug, d=E9pende de la
plateforme mais c'est un peu in=E9vitable.

L'id=E9al serait que le plantage ait lieu bien apr=E8s le bug...=E7a rajout=
e
du piment. Bref, vous voyez l'id=E9e quoi...

J'avais plusieurs pistes d'exploitation de bug:

Piste 1:
Boucle for d=E9croissante sur un entier non sign=E9 : for(size_t i =3D N;
0<=3D i; i--)

Piste 2:
comparaison de double : double x; ... ; x =3D=3D 0.0

Piste 3:
retour de malloc() non test=E9

Piste 4:
caract=E8re de fin de ligne non test=E9 (\0)

Mais jusque l=E0, je crains qu'il ne soit trop facile de d=E9tecter le
bug

J'ai donc ensuite pens=E9 aux r=E9f=E9rences. Mais ce code est encore un pe=
u
trop voyant. Dans le main(), on peut facilement se demander pourquoi
f1 et f2 sont des r=E9f=E9rences, ce qui met directement la puce =E0
l'oreille. Peut =EAtre trouvez vous ce code bien trop compliqu=E9, ou
auriez vous en t=EAte un mani=E8re de "l'am=E9liorer" :-)

A bon entendeur salut.

AG.




#include <iostream>

using namespace std;

#define BUFFER_LENGTH 10

template<int N, class T>
class fifo_circular
{
private:
T * position;
size_t pos_offset;
T buffer[N];

public:
fifo_circular() { pos_offset =3D N-1; position =3D buffer + pos_offset;
for(int i=3D0;i<N;i++) buffer[i]=3DT(0);};

T step(T &input)
{
*position =3D input;

if(pos_offset>0) // ici il y aurait peut =EAtre moyen de glisser le
bug de la piste 1
pos_offset--;
else
pos_offset =3D N-1;

position =3D buffer + pos_offset;
return *position;
};

template<int M, class U> friend ostream & operator<<(ostream & o,
const fifo_circular<M,U> &f);
};

template<int N, class T>
fifo_circular<N,T> & Init(T & value)
{
fifo_circular<N,T> & f =3D fifo_circular<N,T>(); // h=E9 h=E9 h=E9

for(size_t i =3D 0; i < N; i++)
f.step(value);
return f;
}

template<int M, class U>
ostream & operator<<(ostream & o, const fifo_circular<M,U> &f)
{
for(size_t i =3D 0; i < M; i++)
o << f.buffer[i] << " ";
return o;
}

int main(int argc, char * argv[])
{
int a =3D 1;
fifo_circular<5,int> & f1 =3D Init<5,int>(a); // ici, c'est un peu trop
voyant. On se demande pourquoi f1 est d=E9clar=E9 en tant que
r=E9f=E9rence...
a =3D 2;
fifo_circular<5,int> & f2 =3D Init<5,int>(a);

cout << "fifo f1: " << f1 << "\n";
cout << "fifo f2: " << f2 << "\n";

return 0;
}
Signaler un problème avec ce contenu

10 réponses

Supprimer
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire

Veuillez sélectionner un problème

Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
1 2 3 4 5
Avatar
Marc Boyer
Le 30-11-2009, AG a écrit :
As-tu rencontré un exemple dans la vraie vie ?


ça m'est arrivé de mettre plusieurs jours à trouver un bug dans du
code que je n'ai pas écrit.



C'est en effet un point majeur que tu soulignes: c'est vrai
que dans ma pratique, je récupère peu de code extérieur, donc
je n'en ai pas besoin.

Et quand je déboguais du code étudiant, j'avais toujours le
codeur sous la main.

Marc Boyer
--
En prenant aux 10% des francais les plus riches 12% de leurs revenus,
on pourrait doubler les revenus des 10% les plus pauvres.
http://www.inegalites.fr/spip.php?article1&id_mot0
Avatar
Senhon
"Fabien LE LEZ" a écrit dans le message de groupe de
discussion :
On Mon, 30 Nov 2009 08:47:48 -0800 (PST), AG :

Oui, tu auras deviné que j'avais le C en tête lorsque j'ai écrit
cela...



Je pense que tu as mis le doigt sur un point important : il y a pas
mal d'outils qui servent presque exclusivement sur le code des autres.

Celui de Visual Studio l'est.



Oui. Dommage qu'il faille subir, pour l'utiliser, le reste de l'IDE.

C'est d'ailleurs en partie pour ça que j'utilise peu le débogueur :
démarrer le débogueur me force à lancer l'IDE et à y créer un projet,
tâche désagréable à laquelle je ne me résoud que si je ne trouve pas
d'autre solution.



C'est là que tu te trompes énormément.
Je comprends ta vision lorsque, au départ, tu "subis" l'IDE, c'est d'un
frustrant ... je me souviens encore de la mienne et du rejet que cela
induisait.

VisualStudio est énormément pratique quand tu utilises ( dans mon cas ) les
macros ( je ne saurai dire pour les "Modèle objet d'extensibilité").

Il est possible de définir ses propres patrons : de projets [ ou pas de
patron du tout ;-) ], de sources, de fonctions, de classes, de
présentation, ....
En quelques clics ou raccourci clavier, il réalise un travail considérable.
C'est d'une productivité INEGALEE.

Cela demande un investissement au départ, quelques crises de nerfs parce que
l'outils ne réagis pas comme nous avons été formaté par les outils
antérieurs.

Le truc c'est : il faut programmer son propre outils de programmation. Comme
l'écrivait Bjarne Stoupstrup, "... recursive is divine".
Avatar
Michael Doubez
On 1 déc, 11:19, "Senhon" wrote:
"Fabien LE LEZ" a écrit dans le message de grou pe de
discussion :



> On Mon, 30 Nov 2009 08:47:48 -0800 (PST), AG :

>>Oui, tu auras deviné que j'avais le C en tête lorsque j'ai écrit
>>cela...

> Je pense que tu as mis le doigt sur un point important : il y a pas
> mal d'outils qui servent presque exclusivement sur le code des autres.

>>Celui de Visual Studio l'est.

> Oui. Dommage qu'il faille subir, pour l'utiliser, le reste de l'IDE.

> C'est d'ailleurs en partie pour ça que j'utilise peu le débogueur :
> démarrer le débogueur me force à lancer l'IDE et à y créer un projet,
> tâche désagréable à laquelle je ne me résoud que si je ne tro uve pas
> d'autre solution.



C'est peut être pour ça qu'ils ont renommé leur "target" en
"solution" :)

C'est là que tu te trompes énormément.
Je comprends ta vision lorsque, au départ, tu "subis" l'IDE, c'est d'un
frustrant ... je me souviens encore de la mienne et du rejet que cela
induisait.

VisualStudio est énormément pratique quand tu utilises ( dans mon cas ) les
macros ( je ne saurai dire pour les "Modèle objet d'extensibilité").

Il est possible de définir ses propres patrons : de projets [ ou pas de
patron du tout  ;-)  ], de sources, de fonctions, de classes, de
présentation, ....
En quelques clics ou raccourci clavier, il réalise un travail considé rable.
C'est d'une productivité INEGALEE.



Plus vite qu'insérer un patron en quatres touches sans quitter les
mains du clavier ?

Cela demande un investissement au départ, quelques crises de nerfs parc e que
l'outils ne réagis pas comme nous avons été formaté par les outil s
antérieurs.

Le truc c'est : il faut programmer son propre outils de programmation. Co mme
l'écrivait  Bjarne Stoupstrup, "... recursive is divine".



En fait c'est James Coplien.

Et je ne vois pas la relation avec la recursion, programmer un outil
de programmation est un processus itératif.

--
Michael
Avatar
Michael Doubez
On 1 déc, 11:39, Michael Doubez wrote:
On 1 déc, 11:19, "Senhon" wrote:
> Le truc c'est : il faut programmer son propre outils de programmation. Comme
> l'écrivait  Bjarne Stoupstrup, "... recursive is divine".

En fait c'est James Coplien.



Après vérification, c'est Peter Deutsch et Robert Heller.

Désolé pour le bruit.

--
Michael
Avatar
Fabien LE LEZ
On Tue, 1 Dec 2009 02:39:41 -0800 (PST), Michael Doubez
:

Et je ne vois pas la relation avec la recursion, programmer un outil
de programmation est un processus itératif.



L'idée de programmer un outil pour pouvoir programmer, est récursive.
Avatar
Senhon
"Michael Doubez" a écrit dans le message de groupe
de discussion :

On 1 déc, 11:19, "Senhon" wrote:
"Fabien LE LEZ" a écrit dans le message de groupe
de
discussion :




Plus vite qu'insérer un patron en quatres touches sans quitter les
mains du clavier ?



Pour ne parler que de ce que je connais, mon cas perso, un nouveau projet,
avec son fichier contenant un main, ces inclusions, ces initialisations,
tout un tas de truc ch..t à répéter à chaque projet, se déclenche en un
raccourci clavier.


Cela demande un investissement au départ, quelques crises de nerfs parce
que
l'outils ne réagis pas comme nous avons été formaté par les outils
antérieurs.

Le truc c'est : il faut programmer son propre outils de programmation.
Comme
l'écrivait Bjarne Stoupstrup, "... recursive is divine".



En fait c'est James Coplien.



Soit, si tu le dis ... je disais juste que dans un des ses livres (dont le
titre, de mémoire, était "C with Classes"), Stroupstrup écrivait cette
sentence, en tête de chapitre, qui m'avait beaucoup plu.


Et je ne vois pas la relation avec la recursion, programmer un outil
de programmation est un processus itératif.




C'est pas grave, c'était plutôt en clin d'oeil.
Avatar
James Kanze
On Dec 1, 9:02 am, "Senhon" wrote:
"James Kanze" a écrit dans le message
de groupe de discussion :




> On Nov 30, 2:28 pm, "Senhon" wrote:
>> "AG" a écrit dans le message de groupe de discuss ion :
>>



>> GDB, rend d'énormes services.
>> Mais, je n'ai rien trouvé de mieux que Visual Studio, c'est
>> un plaisir que de travailler avec cette merveille. GDB en
>> comparaison fait outil d'un autre âge.



> Là, c'est de l'ironie, n'est-ce pas ? Parce que je me sers
> actuellement de Visual Studio (pour comprendre du code que
> je n'ai pas écrit, et pour lequel il n'y a aucune
> documentation), et je me heurte constamment à ses
> limitations.



Pas du tout, mais alors, loin de là.
Rien que l'usage de la touche F12, fonctionnalité que je n'ai
rencontré nulle part ailleurs, vaut le détour.



Et ça fait quoi, la touche F12 ? Personne ici ne la connaît (et
ils sont pour la plupart des spécialistes du dévelopement sous
Windows).

Bon c'est sûr que dans ton cas, c'est pas ton prog, peut-être
pas ton OS de prédilection, c'est pas ton outils de debug
habituel, lorsque l'on est habitué à une interface
utilisateur, cela gêne pour passer à une autre : et
l'occurrence, entre GDB (commande ligne) et VisualStudio
(graphique), l'écart est déjà conceptuel.



Ce n'est pas l'OS que je connais le mieux, c'est vrai. Je ne
travaille avec Visual Studios et sous Windows que depuis quelque
moins (après environ 20 ans sous Unix). Dans l'ensemble, ça ne
me pose pas de problèmes ; il y a même des choses (pas mal,
d'ailleurs) où je trouve Windows supérieur à Unix. Mais le
debugger, ou bien, personne ici ne le connaît, ou bien, c'est un
désastre. (Aussi, je ne peux pas dire connaître gdb très bien.
Il faut dire que je me suis servi d'un déboggueur peut-être cinq
fois dans les dix dernières années.)

Quelles sont ces limitations que tu rencontre ?



Qu'il n'ait pas de ligne de commande:-). Sérieusement, c'est
plus ou moins ça. J'ai l'habitude de pouvoir afficher n'importe
quelle expression (y compris des expressions qui comporte des
appels de fonctions dans mon code), et de l'afficher
systematiquement, chaque fois que l'exécution s'arrête. Et
l'environement où je travaille fait que je suis bien obligé à me
servir d'un déboggueur ; même l'échec d'une assertion n'arrête
pas le programme.

--
James Kanze
Avatar
James Kanze
On Nov 30, 4:59 pm, AG wrote:
On Nov 30, 5:39 pm, James Kanze
wrote:> Tu vas prétendre que la spécification des
préconditions et des
> invariants n'est pas nécessaire ? Qu'on peut se passer des
> tests unitaires ?



Non bien sûr, mais à l'inverse vas-tu prétendre qu'on est à
l'abri de tout avec les tests unitaires ? Non bien évidemment.
Si on débugge sans débuggeur, c'est forcément que les tests
unitaires ont loupé quelque chose. Arrivé à ce stade, n'est-ce
pas une perte de temps de re-écrire plein de code de débug,
pour finalement compléter les tests unitaires qu'avec un cas
supplémentaire ?



Si on se trouve avec une erreur qui n'est pas détectée par les
tests unitaires, la toute première chose qu'il faut faire, c'est
de créer un test unitaire qui la provoque. Avant de toucher à
quoique ce soit d'autre. Sinon, on saurait jamais si on l'a
corrigé. Et il y aura toujours la risque qu'on la réintroduit à
l'avenir.

--
James Kanze
Avatar
James Kanze
On Nov 30, 6:17 pm, (Marc Espie) wrote:
In article
,
James Kanze wrote:



>Aux l ves, il faudrait plut t l'interdire. Il vaut mieux leur
>apprendre d' crire du code correctement, pourqu'ils n'en ont
>pas besoin d'un d boggueur.



Avec ma population actuelle d'etudiants, je leur montre un
debugger. Il faut voir qu'ils n'ecrivent pas forcement du
code correct, mais qu'ils debugguent a grands coups de printf.
Alors, quitte a debugguer, autant que ca soit efficace...



C'est sûr qu'entre des grands coups de printf et un déboggueur,
il n'y a pas grand choses à dire. Mais ne serait-il pas
préférrable de leur enseigner comment écrire du code d'une façon
à n'avoir besoin ni d'un ni de l'autre.

À la rigueur, je me démande même si je leur autoriserais un
compilateur. Pour au moins un projet.

--
James Kanze
Avatar
James Kanze
On Dec 1, 9:04 am, Michael Doubez wrote:
On 30 nov, 17:39, James Kanze wrote:



[en ce concerne des déboggueurs...]
> Aux élèves, il faudrait plutôt l'interdire. Il vaut mieux leur
> apprendre d'écrire du code correctement, pourqu'ils n'en ont pas
> besoin d'un déboggueur.



Ou mieux: leur apprendre à lire du code correctement.



Les deux vont ensemble. Mais j'aurais dû être plus clair ;
écrire du code correctement, c'est beaucoup plus qu'écrire du
code correct. La lisabilité joue un rôle importante.

Ca leur permettrait de se relire et de lire le code des
autres. Ensuite le debuggueur est dans la tête et ça va plus
vite; puis AMA, en identifiant les points clé d'un programme
ou d'un algo, ils verraient mieux quels tests unitaires
écrire.



Ce qu'il faut, en fait, c'est non seulement que les élèves
écrivent du code, mais qu'ils le fassent lire. Et si la lecteur
n'est pas convaincu que le code est correct, on le rejette ; non
seulement le code doit être correct, il faut qu'il soit
visiblement correct, sans que le lecteur ait besoin d'un effort
particulier pour le comprendre. Ou comme j'ai lu quelque part
(Knuth, je crois), « code is either so simple, it obviously has
no errors, or so complex, it has no obvious errors ». C'est
évidemment le premier qu'il faut viser. (Ou comme disait mon
prof d'anglais au lycée : « good writing is clear and concise » .
Ce qui vaut pour l'anglais vaut aussi pour le C++.)

Ensuite, évidemment : les tests unitaires font partie du
« code ». Il faut qu'il soit aussi évident qu'ils teste tout.

--
James Kanze
1 2 3 4 5