Discussion :

[nicolas.sitbon]

Pour savoir si l'implémentation du compilateur est conforme au standard AINSI C99, la constante

Code :

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

__STD_VERSION__

doit être égale à "199901L".

Toi tu as le livre "C précis et conçis" : je leur ai déjà signalé l'erreur p70 l'auteur parle des macro __STD_HOSTED__ et __STD_VERSION__ alors que c'est __STDC_HOSTED__ et __STDC_VERSION__ , le site signale désormais la seconde erreur http://www.oreilly.fr/archives/C-pkt-errata.txt et je les ai relancé pour la première. Je rappelle le passage de la norme qui explique ces 2 macros :

Code :

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

1
2
_ _STDC_HOSTED_ _ The integer constant 1 if the implementation is a hosted implementation or the integer constant 0 if it is not.
_ _STDC_VERSION_ _ The integer constant 199901L.

[J4e8a16n]

Bonjour à tous,

J'obtiens avec gcc -g monexe

a.exe et non pas a.out

J'obtiens avec gcc -pg monexe
gprof monexe [ou d'autres tentatives du genre]
gmon.out: No such file or directory

[LordMacharius]

Je vais me permettre d'intervenir.

Je précise que je code en C depuis un an de manière intensive (entre 50 a 90H par semaine) et que j'ai pu faire un tour d'ensemble de ce le C propose .

Je constate que le sujet parle de comment déboguer pour les débutants , or un bon nombre des messages que vous avez poster restent obscur même pour moi .

Vous avez oublié que ce qui est évident pour vous ne va pas l'être forcement pour une personne qui va vous lire par la suite .

Ensuite une bonne habitude à prendre est de faire des fonctions courtes (une trentaine de lignes pas plus), car pour déboguer il est plus simple de se pencher sur une fonction qui est courte est facilement isolable du reste du code.

Il ne faut pas hésiter à tester de manière séparé les fonctions que vous codez .
Je développe sous Unix et un bon déboguer dessus serai GDB.

L'indentation est votre amie (oui oui)

La coloration syntaxique est aussi très utile, voire indispensable.

Lire les manuels des fonctions fournis par les bibliothèques.

Ecrire en protocode (ou pseudo-code) ce que vous devez coder
Ex:

Code :

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

1
2
3
4
5
6
7
8
 
fonction => copier une chaine de caracteres
{
   déclarer les variables;
 
   initialiser les variables;
   etc etc .... 
}

Je ne détaille pas mais cela consiste a écrire ce que vous devez faire !

Penser que vous allez devoir libérer la mémoire alloué avec malloc() !

Penser aux différentes erreurs qui risquent de survenir ?

Créer une série de fonctions qui vérifient les valeurs de retour des fonctions système

J'ai du en oublier très certainement !
Je les rajouterais par la suite ...

Si j'ai écrit des choses pas claires pour certains, dites le moi et je me ferais un plaisir de me corriger pour être compris de tous
Edit => le bouton pour me MP est juste en dessous xD

[J4e8a16n]

Merci à vous.


Je peux faire
int ret;
ret = strcmp(str,str1);


Je n'ignorais pas tout ce que vous avez décrit mais ce qui suis me surprend:

Créer une série de fonctions qui vérifient les valeurs de retour des fonctions système .

Par exemple?

Bonjour à tous,
gcc -g -Wextra -Wall -pedantic -std=c99 tst.c
a.exe et non pas a.out

J'obtiens avec gcc -pg monexe
gprof monexe [ou d'autres tentatives du genre]

J'essaie d'être plus clair:

>gcc -g -Wextra -Wall -pedantic -std=c99 tst.c produit a.exe et non pas a.out (comme dans C Unleashed par exemple, ou certains tutoriels de C Developpez)

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
 
gdb tst.exe a.exe
GNU gdb 6.6
Copyright (C) 2006 Free Software Foundation, Inc.
(no debugging symbols found)
 
warning: "C:\cygwin\home\Jean Pierre\tictactoe/a.exe": no core file handler recognize
s format, using default
warning: core file may not match specified executable file.
warning: Couldn't find general-purpose registers in core file.
warning: Couldn't find general-purpose registers in core file.
#0  0x00000000 in ?? ()
(gdb) file a.exe
warning: core file may not match specified executable file.
Reading symbols from C:\cygwin\home\Jean Pierre\tictactoe/a.exe...done.

Si j'utilise la commande file a.exe, gdb trouve les symboles qui s'y trouve.

------------------------
>gcc -pg -Wextra -Wall -pedantic -std=c99 tst.c ne produit aucun fichier pour le profilage.
>gprof tst.exe
Si je tente de 'profiler' monexe, gprof se plaint que gmon.out: No such file or directory


Est-ce tout ce que je peux espérer sous Windows Vista?

JPD

[orfix]

J'essaie d'être plus clair:

>gcc -g -Wextra -Wall -pedantic -std=c99 tst.c produit a.exe et non pas a.out (comme dans C Unleashed par exemple, ou certains tutoriels de C Developpez)

a.out sous *nix et a.exe sous windows.

[MaitreEauEau]

Salut,

Tu ne devrais pas éditer le premier post pour que les solutions soient facile à voir? Parce que là, il faut regarder toute la discussion et ça peut être pénible!

Tu pourrais soit réécrire au complet dans le premier post ou au moins mettre un lien avec une petite description vers ledit post.

A+

[fab_hunter1100]

Beaucoup de chose ont dejà été dites , j ajoute juste ma petite contribution, la difference entre les termes : Error/Fault/Failure , Important car aidant a identifier le bug a savoir où chercher .

Error: Erreure (de pensée) du Programmeur . par exemple confondre les format europeen et americain de la date : dd/mm/yy ou mm/dd/yy , erreures de syntaxe ......

Fault : C est une erreur survenue (peut etre causer par un Error) dans le System . rend le systeme instable et imprevisible . Par exemple chez le client seulement apres avoir entrer un format incorrect que surviendra le "Fault" dans le systeme , pouvant provoquer l arret, ou un comportement bizare .

Failure : Erreur permanente dans le system . Survient quand le systeme ne rempli pas correctement et entierement sa tache . Les "Fault" conduise souvent aux "Failure".

*Solution avant de commencer un Projet :
- Bien s informer sur les Spec et et les standard , appliqué les recommandation , s impregner theoriquement du domaine dans lequel on va travailler ("Il y a rien de plus pratique qu une bonne theorie"), toujours tenir un cahier de charge.

Petit bonus : Considerer les Warnings comme des Erreures , essayer de les faires disparaitre , Si ce n est pas possible , bien documenter les Warnings presents dans le Code et expliquer pourquoi ils n ont pas pu etre dissoute .

[sheldon lee cooper]

Suite a la recrudescence de cas problematique, voici le fruit d'une petite reflexion. Si vous avez d'autre choses a ajouter

Tout d'abord pour debugger un programme, il faut avoir les idees clair deja quant au programme, c'est a dire :
- qu'est-ce qu'il fait
- comment il le fait

et pour aider a cela, rien de tel que du code clair :
- indentation (on decale le code de quelques espaces apres un if, etc.)
- commentaire (telle fonction fait ceci, telle variable contient le resultat, etc.)
- fractionnement des "fonctions" (faire des fonctions generique plutot que d'avoir une fonction de 150 lignes super chiant a debugger)

Ensuite, pour les erreurs de compilations,
- compiler avec le maximum de warnings (-Wall pour gcc). Et comprendre ces warnings : un bon programme ne doit avoir aucun warning : un warning est succeptible de causer une erreur.
- utiliser man (manuel en ligne pour voir la syntaxe des primitives des librairies) (rappel: 'man fprintf' sous linux/unix), ou l'aide en ligne si disponible.
- reflechir au sens des instructions : pourquoi on fait ceci, cela etc.

Enfin, quand vous ne voyez pas l'erreur (et c'est comprehensible), afin de simplifier la tache de ceux qui vont vous aider, il faut specifier au maximum les erreurs rencontrees, en donnant:
- le message d'erreur,
- l'environement utilise (win/linux, compilo, librairies...)
- la ligne du code ou se produit cette erreur
- le code des structures et autres definitions si besoin est (pour montrer les types des donnees utilisees)

Il n'est pas necessaire :
- de donner le code complet (sauf si demande expressement)

Remarque, lorsque du code est donne, il doit l'etre entre les balises [code ] et [/code ]

Petit complément, non pas pour débugger, mais pour éviter les bugs( pas au niveau syntaxique, mais au niveau du comportement du code). Ecrire du code lisible en évitant les "Undefined Behavior". Prendre pour habitude de lire "les normes du C".