Journal Sur l'(in)utilisabilité (relative) de GCC

Posté par  .
Étiquettes : aucune
-37
30
sept.
2008
Il y a des jours^W nuits où je me demande si les développeurs de GCC utilisent leur compilateur de temps en temps ;

xilun@xilun:~/bla$ make 2>&1 | grep error | wc
1145 9106 104917
xilun@xilun:~/bla$ make 2>&1 | wc
1668 11494 136955

1668 lignes dont 1145 d'erreurs (en majorité dans /usr/include) pondues par GCC qui décide que cela vaut tout de même la peine de continuer. Évidemment l'erreur (de syntaxe) est de ma faute à la base, mais est-ce pour autant la peine d'overflooder mon terminal avec de la merde dans laquelle seul ce qui est TOUT EN HAUT m'intéresse.

xilun@xilun:~$ gcc --version
gcc (Debian 4.3.1-9) 4.3.1

  • # Oui

    Posté par  . Évalué à 10.

    parceque une bonne erreur est décrite en long en large et en travers,
    que continuer permet de voir les autres erreurs qui peuvent quand meme exister, qui ne dependent pas forcement de celle la (dure de determiner que l'erreur affecte tout le code et pas une partie).

    moi ca me soulerais encore plus de relancer 15 fois gcc pour 15 petite erreurs (; par-ci, par-la) parceque gcc s'arrette a la premiere.

    j'utilise tj emacs pour compiler, sinon tee est ton amis.

    • [^] # Re: Oui

      Posté par  . Évalué à 5.

      Oui enfin, vu le nombre d'erreurs qui sont des faux positifs provoqués par une erreur un peu plus haut dans le fichier ......

      Je m'étonne que personne n'ai donné -Wfatal-errors:

      -Wfatal-errors
      This option causes the compiler to abort compilation on the first
      error occurred rather than trying to keep going and printing
      further error messages.

      • [^] # Re: Oui

        Posté par  . Évalué à 4.

        Entre 1145 et 1, il devrait y avoir un juste milieu (bien que dans ce cas précis 1 m'aurais suffit)

        Toute personne ayant déjà oublié un ";" à la fin d'un prototype dans un header a été confronté au délire de GCC souhaitant "rattraper" les erreurs de syntaxe (toutes...) pour être "gentil", et à donc le réflexe intuitif de regarder l'incompréhensible première erreur uniquement pour récupérer le numéro de ligne (en sachant par avance qu'on aura 99% de chance de fixer le truc en y mettant ";" à la fin).

        Bref la correction du problème qui a entraîné la rédaction de ce journal m'a pris moins d'une minute (parce que confronté régulièrement à ce genre d'idioties, j'ai pris la précaution depuis lontemps de régler le tampon de mes terminaux à un nombre de lignes délirant ce qui m'a permis de remonter sans même relancer le build). Ce que je voulais dénoncer, c'est le manque de pragmatisme, de concessions. Y-a-t'il _vraiment_ une personne sur terre qui a déjà trouvé 1145 erreurs de compilation utiles au delà de disons, prenons _très_ large, ... les 100 premières ? -> et hop un peu de pragmatisme et une valeur par défaut saine (quitte à rajouter une option pour régler précisément le comportement pour éviter que les gens ralent devant une telle limitation scandaleuse, même si jamais personne n'utilisera en pratique la-dite option)

        Pour info mon programme fait ~6000 lignes selon sloccount. Je n'ose imaginer la quantité de faux positifs potentiellement provoqués par une erreur dans un header de certains projets de 300k lignes.

        • [^] # Re: Oui

          Posté par  . Évalué à 1.

          Je sais pas avec quoi tu codes, mais ton soft ne fait pas de la compil' à-la-volée ? Afin de te montrer dès l'écriture du code, les erreurs les plus facilement détectables (';' oubliés, noms de fonction inconnus car erronés...) ?

          Cela fait partie, selon moi, du B-A BA de tout bon IDE (avec la coloration syntaxique et la complétion du code)...


          Bref, selon moi, ce genre d'erreurs détectables à la compilation ne devrait du coup jamais arriver lorsqu'on lance la compilation de tout le bouzin !
          Ou alors, je suis trop habitué à coder en Java avec Eclipse...

          • [^] # Re: Oui

            Posté par  . Évalué à 2.

            Le problème c'est que le C est probablement plus "ambigu" que le Java quand on fait une erreur de syntaxe, surtout en ce qui concerne les proto et si on continue de supporter la syntaxe K&R.

            De plus je ne me suis pas habitué à utiliser un IDE sous Linux lors de mes débuts sous cet OS et j'ai du mal à changer cette habitude - avant 2000 y'avait pas grand chose qui arrivait ne serait-ce qu'à la hauteur d'un bon vieux Turbo C sous DOS ergonomiquement parlant, et les vim et emacs étaient trop exotique de mon point de vue => je vais probablement faire dresser les cheveux sur la tête de quelqu'uns (et rappeler des souvenirs à d'autres) mais je codais sous mcedit à l'époque (sur un 486). Aujourd'hui X-Window me permet d'avoir autant de terminaux que je veux dans lesquels je mélange des builds et d'autres choses, donc je n'accroche pas plus sur les IDE - d'autant que je bosse typiquement sur un assez grand nombre de paquets, mais plutôt de manière très ponctuelle sur chaque, et que des grands coups de rgrep dans un shell donne de meilleurs résultats dans ce cas là.

  • # Simple

    Posté par  . Évalué à 9.

    Si je pouvais, je moinserais...

    make 2>&1 | head

  • # jour & nuit

    Posté par  (site web personnel) . Évalué à 10.

    Il y a des jours^W nuits où je me demande si les développeurs de GCC

    Comme quoi la nuit, il vaut mieux dormir. La fatigue nous fait parfois pondre des journaux pas très utils.

  • # Commentaire supprimé

    Posté par  . Évalué à 4.

    Ce commentaire a été supprimé par l’équipe de modération.

    • [^] # Re: Quelques questions

      Posté par  . Évalué à 4.

      Ce que j'aime bien dans les compilateurs Microsoft c'est le code d'erreur qui est retourné (ex : C4443). De cette façon il est plus facile de trouver des infos sur les problèmes de compilation via google.

      • [^] # Re: Quelques questions

        Posté par  (site web personnel) . Évalué à 6.

        en effet et c'est d'autant plus utile une fois qu'un quelconque bras-cassé à décidé que ça serait une bonne idée de traduire les messages d'erreur en français, en breton etc. , parce qu'avec gcc il ne te reste rien à quoi te racrocher une fois que ton compilateur te parle de "jeton invalide" et autres niaiseries

  • # man gcc

    Posté par  (site web personnel) . Évalué à 4.

    -Werror

    • [^] # Re: man gcc

      Posté par  (site web personnel) . Évalué à 3.

      Euh, en quoi ça répond au problème, ça ?

      • [^] # Re: man gcc

        Posté par  . Évalué à 3.

        Il voulait surement dire -Wfatal-errors, qui fait que GCC s'arrête à la première erreur.

  • # J'aime bien ce comportement moi !

    Posté par  (Mastodon) . Évalué à 5.

    J'aime bien ce comportement moi ! En effet, je préfère un outil qui a un fonctionnement basique, pour pas dire bourin : je compile tout ce que je peux, je balance les erreurs à chaque fois que j'en vois une (parce que les 1000 lignes correspondent à plusieurs centaines d'erreurs, qui, certes, ont une origine commune dans ton cas).

    Ensuite à toi, selon ce que tu veux, de manipuler ce comportement (via des '|', ou des options, il y en a plusieurs de citées dans les autres commentaires).

    Si tu n'avais que 3 ou 4 erreurs, tu dirais : "pourquoi il me montre que la première, alors que si il me les montrait toutes, je pourrais les corriger d'un coup ?"

    Comportement complexe = plus de bugs, c'est inéluctable. C'est justement ce que je reproche 9 fois sur 10 aux produits Microsoft : "mais de quoi ils se mèlent !!!"

    En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

    • [^] # Re: J'aime bien ce comportement moi !

      Posté par  . Évalué à 7.

      D'autant plus que si ton projet est bien fait, tu as un max de petits fichiers c/c++ à compiler et quand il plante sur l'un d'entre eux, il ne s'arrête pas pour autant de compiler les autres qui sont *eux* peut être sains... et donc autant de .o à ne pas recréer au prochain make.

      Ce que je déteste le plus, c'est de lancer une compile *sensé* être longue, aller prendre un café, et me rendre compte en revenant qu'il s'est arrêté à la deuxième ligne de code pour une excuse aussi peu valable que "Internal Compiler Error" ... pfffft visual roulez qu'ils disaient.

    • [^] # Re: J'aime bien ce comportement moi !

      Posté par  (site web personnel) . Évalué à 2.

      > Comportement complexe = plus de bugs

      Euh, si c'est ça l'argument, ça prêche en faveur de l'arret à la première erreur, non ? La récupération d'erreur dans les compilateurs, c'est une question pas évident à résoudre correctement (et GCC est particulièrement mauvais sur ce point), la solution triviale, c'est de s'arrêter de suite.

  • # IDE

    Posté par  . Évalué à 8.

    Avec un IDE (qui peut utiliser gcc) tu as la liste des erreurs, il suffit de cliquer sur l'erreur (ou l'avertissement) et il t'ouvre le fichier à la bonne ligne. Ainsi avec une compilation du corrige plusieurs erreurs/avertissements.

  • # Sur l'introspection...

    Posté par  . Évalué à 8.

    A moins d'être sûr de son absolue connaissance en tout, il convient souvent de réfléchir au pourquoi les choses sont telles quelles sont (avantages et inconvénients) et quelques fois de se remettre en question avant de dresser un bilan...

    Il arrive de nombreuses fois dans l'utilisation de l'informatique qu'on trouve des outils bien trop complexes et qu'on se dit bien que ça devrait être beaucoup plus simple mais bien souvent les choix sont réfléchis et c'est parce qu'on ne perçoit pas l'ensemble des tenants et aboutissant qu'on produit une mauvaise réflexion.

    Quoiqu'il en soit ta méthode pour obtenir de l'aide est somme toute bien trouvée.....

  • # ta faute

    Posté par  (Mastodon) . Évalué à 6.

    Comme tu dis, c'est ta faute... si tu ne veux pas que GCC ne crache à la tête, sois plus rigoureux quand tu codes, regardes à deux fois si tu n'as pas oublié le ";" à la fin, fais une vérification sommaire des erreurs classiques, etc. Autre possibilité, compile le plus tôt possible ton fichier, n'attends pas d'avoir écrit 1000 lignes pour compiler, sinon, effectivement, paf le chien. GCC, il fait ce que tu lui dis de faire, c'est un programme, il est con, par contre toi tu es intelligent et tu peux résoudre ce problème.

    • [^] # Re: ta faute

      Posté par  . Évalué à 3.

      Ouais, t'as aussi des trucs comme eclipse en java qui aident pas mal à défricher les problèmes syntaxiques de bases, et même un peu plus, genre correcteur ortho-grammatical dans un traîtement de texte.

  • # Euh...

    Posté par  . Évalué à 3.

    Tu te plains de gcc qui continue à compiler, alors que ce n'est aucunement de sa faute*.
    J'ai plutôt l'impression que c'est ton Makefile qui dit de continuer...

    * sauf s'il n'y a qu'une commande dans le Makefile

    Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.

    • [^] # Re: Euh...

      Posté par  . Évalué à 2.

      Ces erreurs 1145 erreurs dont 1144 faux positifs sont dues à la compilation d'un seul module (et plus précisement à l'absence d'_un_ ";" à la fin d'un prototype dans un header).

  • # Petite note

    Posté par  (site web personnel) . Évalué à 4.

    Je pense que tu n'as jamais implanté de compilateur.

    Les gestion des erreurs de compilation, c'est une tâche *vraiment* lourde dans l'écriture d'un compilo (ou même d'un interpréteur).
    Quand on voit la taille de GCC, on se dit qu'il est rudement bon quand même !

    Cela étant, oui, c'est un peu fatiguant de décortiquer l'erreur (vraiment une erreur de syntaxe ? un bug dans GCC ? un typo dans mon code ?)

    Mais on s'y fait vite, car chaque classe d'erreurs génère en fait un type d'erreur identique... De plus, les IDEs, et éditeurs (y compris VIM) te mettent le curseur sur la première erreur trouvée (et les suivantes si tu cliquouilles ou tape la bonne commande (:cnext, :cc par exemple avec vim))

    • [^] # Re: Petite note

      Posté par  . Évalué à 2.

      Je pense que tu n'as jamais implanté de compilateur.

      Les gestion des erreurs de compilation, c'est une tâche *vraiment* lourde dans l'écriture d'un compilo (ou même d'un interpréteur).

      Le coup de "c'est dur" ou "tu sais pas le faire" n'est pas une "excuse" valable. Ca peut etre une explication, mais pas une excuse.

      Oui une tache peut être très lourde et difficile, est ce pour autant qu'il faut faire n'importe quoi (attention je ne parle pas de gcc mais en général) ?
      Bien sur que non.

      • [^] # Re: Petite note

        Posté par  (site web personnel) . Évalué à 2.

        Je ne suis pas dev de GCC, mais des compilos et interprètes, j'en ai écrit plus d'un, et je continue.

        Et si l'"excuse" ne te satisfait pas, alors j'y peux rien.
        Ils n'ont pas à s'excuser auprès de toi (ou de quiconque), mais *tu* dois te contenter de la justification ou utiliser un autre programme (ou mieux ! patcher GCC)

        Mais trimballe toi un AST avec informations de types, positions des tokens, et essaye de remonter à la transformation de code ou à l'evaluation partielle qui a généré l'erreur, et on en reparlera...

        Fais le juste pour un interprète d'expressions arithmétiques...
        Tu verras que se contenter d'un comportement basique ne signifie en rien "faire n'importe quoi".

        Te dire "on va juste garde la ligne du token", ca peut vouloir dire immédiatement des *milliers* de répercussions sur ton code... (bon, tu dois pouvoir embarquer ça dans une monade ou toute autre bonne abstraction fonctionnelle, mais comme les gens veulent toujours coder dans des langages pas forcément adaptés aux tâches qu'ils doivent résoudre...)

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.