En fait je n'ai jamais dit que les warnings étaient des erreurs.

Ce que je dis, c'est qu'en mettant l'option -Werror,  le débutant doit s'intéresser en priorité à ce que le compilateur lui fait savoir à propos de son code. Ça lui enlève l'illusion que, si ça compile et que ça marche sur un exemple, c'est bon même si le compilo couine.

Et en pratique, s'arranger pour que le compilateur soit d'accord sur le fait qu'on déclare clairement son intention, y compris en reglant le cas des warnings qui ne sont quand même pas des futilités, c'est pas compliqué ( un exercice de débutant qui montre le contraire ?).

Et c'est même un des principes que tu aimes citer.

Je n'ai pas dit non plus qu'il ne fallait pas savoir lancer un debugger pour debugger, un pprofiler pour savoir où passe le temps d'exécution, ou valgrind pour localiser les fuites, ou un framework de tests unitaires, ou un système de gestion des sources, ou des machines virtuelles pour tester sous différents environnements.

Mais bon, pour commencer, c'est peut être mieux d'apprendre à lire les messages et à en tenir compte ?

-
Edité par michelbillaud 3 avril 2021 à 8:02:26

michelbillaud a écrit:

En fait je n'ai jamais dit que les warnings étaient des erreurs.

[...]
-

Edité par michelbillaud il y a moins de 30s

Bah si … par exemple ton message précédent commence par :

michelbillaud a écrit:

White Crow a écrit:

Comment peut-il débusquer une erreur s'il n'a pas d'exécutable à lancer afin de constater à quoi correspond (ou non) le choix de laisser passer un warning ?

Une erreur évitée, c'est une erreur qu'on n'a pas à chercher à l'exécution.

[...]

-
Edité par michelbillaud il y a environ 10 heures

Je te parle de warning (qui peut ne pas être une erreur) et tu ne me parle que d'erreurs … je ne te parle que de warning …

Utiliser -Werror c'est traiter inconditionnellement sans discernement tous warnings comme des erreurs fatales empêchant la compilation …

michelbillaud a écrit:

[...]

Ce que je dis, c'est qu'en mettant l'option -Werror,  le débutant doit s'intéresser en priorité à ce que le compilateur lui fait savoir à propos de son code. Ça lui enlève l'illusion que, si ça compile et que ça marche sur un exemple, c'est bon même si le compilo couine. 

c'est kif kif bourricot … ça oblige le débutant à tout faire pour faire taire le warning … y compris des choses idiotes en lui donnant l'illusion que si ça compile sans erreur alors c'est bon …

michelbillaud a écrit:

[...]

Et en pratique, s'arranger pour que le compilateur soit d'accord sur le fait qu'on déclare clairement son intention, c'est pas compliqué ( un exercice de débutant qui montre le contraire ?). Et c'est même un des principes que tu aimes citer.

Non, c'est un extrait du K&R 2 que tu as cité … et cet extrait (relis le bien) concerne surtout le transtypage entier/pointeur muet dans les premières versions. Et bien que ce soient des warnings justifiés, ils n'ont jamais empêché une compilation d'aboutir. Ce sont resté des warnings, et ne sont pas diagnostiqués comme erreur.

Les principes que je cite sont ceux qui, en partie, définisse C et qui sont rappelés par le comité de standardisation. Ceux que j'aime à citer sont ceux qui sont bafoués par le -Werror → le programmeur sait ce qu'il fait et ne pas empêcher le programmeur de faire ce qu'il faut.

Et honnêtement, quitte à apprendre C autant le faire en sachant où l'on met les pieds (même s'il arrive que l'on se tire une balle dedans).

Mais, c'est parce que tu as tronqué ta citation du standard C99, qui est précédée par

« Keep the spirit of C. The C89 Committee kept as a major goal to preserve the traditional spirit of C. There are many facets of the spirit of C, but the essence is a community sentiment of the underlying principles upon which the C language is based. Some of the facets of the spirit of C can be summarized in phrases like: »

Introduction, page 3, vers ligne 15, http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf

Bref, pour une vue plus complète des multiples facettes de l'esprit de C, il faut chercher ailleurs, plus près des origines. Quelqu'un de mieux placé que K+R à proposer ?


Et à ma connaissance, le comité de normalisation n'a pas jugé pertinent de renouveler ce serment de fidélité à l'Esprit des Grands Ancêtres dans les standards suivants

• pas de "spirit" dans le draft C11,
  
• 2 occurrences dans le C2x, mais pour autre chose. 

-
Edité par michelbillaud 3 avril 2021 à 14:35:26

Bon je redonne un lien (pour la troisième fois, mais ici dans sa dernière version) qui montre que ce que tu racontes c'est un peu n'imp.

Donc le lien vers la charte acceptée pour la nouvelle norme C23 → http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2611.htm 

Tu remarqueras que c'est bien la source utilisée pour écrire ce que j'ai écrit, qu'à son époque il y en avait pour C99 et C11 et, enfin comme tu dis :

michelbillaud a écrit:

le catalogue d'options -W ? que veux-tu en faire ?   Si tu ne dis pas en une phrase claire à quoi tu fais référence, ça n'a aucun intérêt de le citer.

Sinon, je peux aussi t'envoyer sur http://www.open-std.org/jtc1/sc22/wg14/  pour témoigner de toutes les évolutions envisagées par les comités. Les tableaux de première classe. Les classes en C. Le restrict qui a fait criser kernighan (pour qui const était déjà une abomination) etc.

-
Edité par michelbillaud 31 mars 2021 à 21:24:44

tu aurais sans doute eu intérêt à suivre ton propre lien … un tout petit plus loin … http://www.open-std.org/jtc1/sc22/wg14/www/docs/

Après je suis désolé si la référence n'est pas assez ancienne ou pas assez à ton goût ^_^

Ce document parle du NEW spirit qui est donc différent de l'ancien .

Justement, pour c11 "trust the programmer, as a goal, is outdated"

Je savais bien que je ne l'avais pas inventé, merci d'avoir retrouvé la référence.

-
Edité par michelbillaud 3 avril 2021 à 16:46:35

michelbillaud a écrit:

Ce document parle du NEW spirit qui est donc différent de l'ancien .

Justement, pour c11 "trust the programmer, as a goal, is outdated"

Je savais bien que je ne l'avais pas inventé, merci d'avoir retrouvé la référence.

-
Edité par michelbillaud il y a 8 minutes

Bon ben tant qu'à faire autant bien citer … sans faire preuve de mauvaise foi :

The new spirit of C can be summarized in phrases like:

(a) Trust the programmer.
(b) Don't prevent the programmer from doing what needs to be done.
(c) Keep the language small and simple.
(d) Provide only one way to do an operation.
(e) Make it fast, even if it is not guaranteed to be portable.
(f) Make support for safety and security demonstrable.

et évidemment :

12. Trust the programmer, as a goal, is outdated in respect to the security and safety programming communities. While it should not be totally disregarded as a facet of the spirit of C, the C11 version of the C Standard should take into account that programmers need the ability to check their work.

Ça fait 10 ans que c'est d'actualité …

D'autres questions ? ou remarques ?

Edit: évidemment tout est intégralement tiré de (et hop jamais 3 sans 4 … http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2611.htm )

Edit 2 : en fait tu ne lis pas les références que je donne, tu ne les regarde même pas … tu ne fais que réagir instinctivement à ça. Me trompe-je ?

-
Edité par White Crow 3 avril 2021 à 17:05:52

Si tu tires des conclusions du fait que je réponds vite, tu peux pas savoir, mais il se trouve que je suis un lecteur très rapide (my life : j'ai grandi dans une librairie, et y avait pas grand chose d'autre à faire que de bouquiner).

Mais bon, si tu veux, on fait ensemble une analyse de texte

1. ce document a une première section, qui rappelle les principes d'origine (certaines facettes de)

Original Principles

Before embarking on a revision of the C Standard, it is useful to reflect on the charter of the original drafting committee

avec "Keep the spirit of C. The Committee kept as a major goal to preserve the traditional spirit of C. There are many facets of the spirit of C," etc.

(les 7 que tu cites)

Donc on est bien d'accord, avec toute la bonne foi du monde, que ça parle du boulot du comité qui a préparé C89 ? Le ci-devant "original drafting comitee".

Parce qu'il faut lire au delà ...

2. La section suivante décrit l'évolution pour C99

Additional Principles for C99

(ajouter l'internationalisation etc)

3. puis ceux pour C11

Additional Principles for C11

12. Trust the programmer, as a goal, is outdated in respect to the security and safety programming communities. While it should not be totally disregarded as a facet of the spirit of C, the C11 version of the C Standard should take into account that programmers need the ability to check their work.

13. Unlike for C99, the consensus at the London meeting was that there should be no invention, without exception. (...)

14. Migration of an existing code base is an issue. The ability to mix and match C89, C99, and C11 based code is a feature that should be considered for each proposal.

Puis celui pour C23 (self documenting API), et des observations, comme quoi aucun principe n'est absolu, d'autant qu'il faut trouver un compromis entre eux (non dit : ils sont contradictoires, comme tous les bons principes dans la vraie vie).  

Bref, depuis C11 il faut renforcer les vérifications parce qu'on ne peut plus raisonnablement laisser toute la responsabilité sur les épaules du programmeur. Mai s quand même on est coincés par la base de code existant (comme pour tous les langages qui ont eu du succès) qu'on ne peut pas se permettre de rendre "officiellement incorrecte". Et si vous voulez des innovations dans le langage, allez voir chez les voisins (C++) nous on maintient juste le truc à flot.

La conclusion logique, c'est que les problèmes détectés par le renforcement des contrôles de sécurité se traduiront par des warnings, et non des erreurs. Au grand désespoir du comité, mais bon, principe 14, on peut pas se permettre de tout péter.

---

Bref, les principes ont évolué, et aujourd'hui on essaie de former les "codeurs" avec la vision des choses de maintenant, pas celle d'il y a 30 ans.

Et clairement [the programmer]" need the ability to check their work", c'est un impératif maintenant.

-
Edité par michelbillaud 3 avril 2021 à 18:06:05

michelbillaud a écrit:

Si tu tires des conclusions du fait que je réponds vite, tu peux pas savoir, mais il se trouve que je suis un lecteur très rapide (my life : j'ai grandi dans une librairie, et y avait pas grand chose d'autre à faire que de bouquiner).

Rapide sans doute, mais consciencieux non …

tu réagis à la troisième mention du doc …
tu pars dans ta lecture qui n'a rien à voir avec mes propos …
tout est bon pour avoir raison … mauvaise foi comprise, citation tronquée, éclatement dans tous les sens, …

Bon je te laisse le dernier commentaire comme ça tu auras au moins le sentiment de sortir vainqueur de ce monologue … enfin à moins que tu ne racontes de grosses bêtises s'entend…

Tu fais comme tu veux, jusqu'ici

• ce que j'ai compris de ton point de vue c'est "conseiller aux débutants de mettre l'option -Werror est une mauvaise idée"
• Mais peut être que je me trompe, dans ce cas il faudrait préciser
• je n'ai pas vu d'argumentation construite pour soutenir ce point de vue, la référence à "l'esprit originel de C", quoi que ça puisse être, outre qu'elle est fumeuse, n'a pas de lien avec l'option -Werror, ni avec l'enseignement aux débutants.
• En arriver aux attaques personnelles, ultime stratagème :-)

-
Edité par michelbillaud 3 avril 2021 à 20:29:21

michelbillaud a écrit:

Tu fais comme tu veux, jusqu'ici

• ce que j'ai compris de ton point de vue c'est "conseiller aux débutants de mettre l'option -Werror est une mauvaise idée"
• Mais peut être que je me trompe, dans ce cas il faudrait préciser

Bravo … tu as compris ce que je disais, c'est un peu réducteur mais c'est l'esprit. Encore plus simple : «conseiller l'option -Werror est une très mauvaise idée, l'utiliser encore plus, surtout de concert avec les -Wall -Wextra». Tu remarqueras que débutant ou non a priori je m'en fous, -Werror c'est la fausse bonne idée.

michelbillaud a écrit:

• je n'ai pas vu d'argumentation construite pour soutenir ce point de vue, la référence à "l'esprit originel de C", quoi que ça puisse être, outre qu'elle est fumeuse, n'a pas de lien avec l'option -Werror, ni avec l'enseignement aux débutants.

Car tu ne lis pas ce qui est écrit. Parfois tu t'embourbes et ça part en mauvaise foi (je ne t'attaque pas, je le constate et je l'ai détaillé) sans oublier les commentaires qui digressent, pour noyer le poisson ? qui sait … Et la non plus ce n'est pas une attaque, c'est une constatation.

Tu vois, rien que ce que tu appelles l'esprit originel du C fait partie de tes interventions … uniquement. Petite analyse post-mortem :

Le premier message où je parle de l'esprit C →

White Crow a écrit:

[...]
L'esprit du C :

• Trust the programmer.
• Don't prevent the programmer from doing what needs to be done.
• Keep the language small and simple.
• Provide only one way to do an operation.
• Make it fast, even if it is not guaranteed to be portable.
• Make support for safety and security demonstrable.

Et on peut d'autant plus croire le dèv qu'on possède un compilo qui diagnostique bien, et un -Werror c'est juste empêcher le dèv de faire ce qu'il faut (parfois) …

Enfin, ce n'est que mon avis hein 😇

Juste de l'esprit du C hein … par l'esprit originel ou primordial ou … non, juste l'esprit du C tel qu'il est explicité dans la charte de la (future) norme C23.

Tu y réagis car justement tu ne fais pas le lien avec ce document … tu ne le connais pas (et c'est pas grave hein), mais tu l'interprètes à tort.

michelbillaud a écrit:

[...]

Les points que tu cites comme étant "l'esprit du C " etaient un article de foi du premier standard "le programmeur infaillible sait ce qu'il fait LOL", le comité de normalisation est un peu revenu sur terre ensuite.

-

Edité par michelbillaud 31 mars 2021 à 0:03:36

Comme je me rends plus ou moins compte que ça ne te dit rien je me permet de te donner le lien vers le document … lien que j'aurais sans doute dû mettre en URL explicite car tu n'as pas l'habitude de suivre des liens textuels.

White Crow a écrit:

michelbillaud a écrit:

Les points que tu cites comme étant "l'esprit du C " etaient un article de foi du premier standard "le programmeur infaillible sait ce qu'il fait LOL", le comité de normalisation est un peu revenu sur terre ensuite.

Ces points font toujours partie intégrante de la charte concernant le futur standard C2x …bien que tu le tournes en dérision c'est aussi ça le C. Et justement ce que tu écris «comme étant un peu revenu sur terre ensuite» est juste une mauvaise vision de ce que le C est et devient. Je ne fais, dans mon message précédent, que retranscrire ce que le WG14 exprime et souhaite.

Le -Werror était peut-etre utile en C89 lorsque les messages du compilo étaient aussi abscons qu'une prophétie d'un oracle de Delphes. Ce qui aurait pu faire naître l'idée qu'un warning c'est une erreur mal diagnostiquée et qu'il fallait s'en débarrasser comme d'une sangsue quitte à utiliser un mégot de cigarette.

Mais on est un peu en 2021, les choses ont évoluées. Les compilos indiquent réellement un problème potentiel. Pas un problème qu'ils n'ont pas pu diagnostiquer comme une erreur, mais réellement un problème potentiel. Et pour t'en convaincre il suffit de lire la doc. Prends, par exemple, le manuel de gcc, liste les diagnostiques émis en utilisant -Wall -Wextra. Regarde les exemples donnés (oui, la doc est bien  faite). Prenons un exemple : -Wstring-compare qui est inclus dans -Wextra. Cette option émet un warning si au moment de la compilation gcc détecte qu'une comparaison où strcmp/strncmp intervient est constante et fausse. Est-cde une erreur dans le code ? ptêt, mais il existe des codes tout à fait valides pour qui cet avertissement n'est pas une erreur.

Le pire, cher Michel, le pire étant que «tu ne retrouvais pas la référence» mais que je te la donnais … il te suffisait de suivre le lien …

Tu pourras aisément comprendre que par la suite je puisse te soupçonner soit de mauvaise foi soit de ne pas lire mes propos et d'y réagir uniquement en n'utilisant que la partie la plus archaïque de ton cerveau.

Je pencherai évidemment pour la mauvaise foi, en relisant ton message tronquant «ce que tu cherchais et que je donnais» ; moui, il aura fallu que je te donne trois fois le lien pour que tu ailles juste y jeter un œil.

Et ce qui montre que tu ne lis pas ce que je t'écris, c'est ton «attaque» →

michelbillaud a écrit:

Mais, c'est parce que tu as tronqué ta citation du standard C99, qui est précédée par

« Keep the spirit of C. The C89 Committee kept as a major goal to preserve the traditional spirit of C. There are many facets of the spirit of C, but the essence is a community sentiment of the underlying principles upon which the C language is based. Some of the facets of the spirit of C can be summarized in phrases like: »-

Edité par michelbillaud il y a environ 9 heures

Bah oui … non seulement je te donne les liens mais tu en cherches d'autres ???? c'est quoi ça ??? si ce n'est de la mauvaise foi ???

J'ai toujours essayé de te recentrer sur le cœur du sujet …

Je finirais avec une petite cerise sur le gateau le 3 avril vers 15H →

michelbillaud a écrit:

blablabla

12. Trust the programmer, as a goal, is outdated in respect to the security and safety programming communities. While it should not be totally disregarded as a facet of the spirit of C, the C11 version of the C Standard should take into account that programmers need the ability to check their work.

-

Edité par michelbillaud il y a environ 5 heures

Alors que 3 jours plus tôt :

White Crow a écrit:

ça doit … sans doute.

L'important reste :

«Keep the spirit of C.

The Committee kept as a major goal to preserve the traditional spirit of C. There are many facets of the spirit of C, but the essence is a community sentiment of the underlying principles upon which the C language is based»

et 

«Trust the programmer, as a goal, is outdated in respect to the security and safety programming communities. While it should not be totally disregarded as a facet of the spirit of C, the C11 version of the C Standard should take into account that programmers need the ability to check their work.»

Exactement ce que je raconte dans toute cette discussion …

Il se peut que j'ai loupé quelque chose en lisant trop vite la première fois.

Bref, on est d'accord que l'opinion que l'usage de -Werror est une fausse bonne idée ne peut pas être étayée par une évocation de la soi-disant philosophie, des prétendus principes originels de C, qui sont d'ailleurs réévalués depuis 10 ans ?

Donc, retour au depart, qu'est ce qui te fait dire que l'usage de -Werror est une mauvaise idée, à part que ça prive le débutant du plaisir de constater que le programme sur lequel le compilateur a couiné plante parfois (si on a la malchance de tomber sur un exemple) pour les raisons qu'il lui avait indiqué ? Et que ça apprend la vraie vie  à l'apprenant

 Ps: si j'ai l'air de chipoter et d'être contrariant, c'est (en plus que je suis un peu con) parce qu'on n'est pas là pour être d'accord, mais pour confronter des points de vue différents, pousser les raisonnements (à la limite de la mauvaise foi, si tu veux)  pour voir ce que ça donne. Ce qui permet de se faire avancer les choses, si on n'a pas d'opinions définitives.

-
Edité par michelbillaud 4 avril 2021 à 9:18:10

michelbillaud a écrit:

Il se peut que j'ai loupé quelque chose en lisant trop vite la première fois.

tu es euphémisant, pour le moins.

michelbillaud a écrit:

Bref, on est d'accord que l'opinion que l'usage de -Werror est une fausse bonne idée ne peut pas être étayée par une évocation de la soi-disant philosophie, des prétendus principes originels de C, qui sont d'ailleurs réévalués depuis 10 ans ?

-

Edité par michelbillaud il y a environ 9 heures

Bien sûr que non … 

White Crow a écrit:

[...]

Je ne dis pas qu'il ne faut pas le vérifier, je dis que ça ne doit en aucun cas être bloquant.

Et oui, c'est là où la philosophie du C (le programmeur sait ce qu'il fait) intervient. Si tu veux une compilation qui passe sans aucun message pour avoir un exécutable alors ne fait pas du C, fait de l'Ada ou du Rust (et encore … rust ça va).

L'esprit du C :

• Trust the programmer.
• Don't prevent the programmer from doing what needs to be done.
• Keep the language small and simple.
• Provide only one way to do an operation.
• Make it fast, even if it is not guaranteed to be portable.
• Make support for safety and security demonstrable.

Et on peut d'autant plus croire le dèv qu'on possède un compilo qui diagnostique bien, et un -Werror c'est juste empêcher le dèv de faire ce qu'il faut (parfois) …

Dans la charte C23 (as-tu encore besoin du lien ? bon juste au cas où … http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2611.htm )

Important Observations

During the revision process, it will be important to consider the following observations:

• Regarding the 15 principles, there is a tradeoff between them—none is absolute. However, the more the committee deviates from them, the more rationale needed to explain the deviation.

Donc la ligne de conduite a évoluée (heureusement) mais pas déviée … Le C c'est aussi sa philosophie, que tu le veuilles ou non.

Et je me permets de te rappeler la nième fois que tu es le seul à parler des principes originels … ce sont des principes toujours actuels … lis la charte C23.

Sérieusement, prends le temps de lire la charte … s'il te plaît.

michelbillaud a écrit:

Donc, retour au depart, qu'est ce qui te fait dire que l'usage de -Werror est une mauvaise idée, à part que ça prive le débutant du plaisir de constater que le programme sur lequel le compilateur a couiné plante parfois (si on a la malchance de tomber sur un exemple) pour les raisons qu'il lui avait indiqué ? Et que ça apprend la vraie vie  à l'apprenant

-

Edité par michelbillaud il y a environ 9 heures

bah oui … parce que tu es incapable de lire mes messages précédents.

Bon je vais simplement dessiner le cadre de ma pensée, tu pourras compléter en relisant mes messages … ok ?

• -Werror implique éliminer les warnings pour pouvoir disposer d'un exécutable ;
• éliminer les warnings n'incite en rien un débutant «à se pencher sur le warning pour le comprendre et le résoudre» (et même pas le cas échéant à cause de l'ineptie du «on traite les warnings comme des erreurs même si un warning n'est pas une erreur» ;
• le ebutant aura peut être modifié le code incorrectement ou inutilement ;
• le code peut planter (suite à l'introduction d'un UB par exemple) ;
• le débutant essayera de debuguer l'exécutable sans se souvenir ou sans avoir l'indication quelconque du warning mal corrigé par obligation  …
• le débutant se sent couillon de t'avoir écouté quand il se rend compte de tout cela.

Tout cela se re trouve dans mes commentaires précédents … ceux que tu n'as pas été capable de lire apparemment.

Comme en partie ici

White Crow a écrit:

michelbillaud a écrit:

Dans ton cast sauvage, c'est une erreur qui ne se corrige ni par un cast, ni par une absence de cast. Les avertissement signalent un probleme potentiel, mettre WError oblige à se pencher dessus. Mais bien sûr ils n'empecheront personne d'être stupide. Je ne vois pas où est l'argument. 

Ce n'est pas lw -Werror qui t'oblige à te pencher dessus. le -Werror t'oblige à le faire disparaître. Que ce soit un débutant ou non, cela peut ne pas être de la meilleure des façons. Et si la «correction» ne résout que le problème de faire disparaître un message du compilo pour pouvoir avoir un exécutable à tester au lieu corriger le bug potentiel sans pouvoir même lancer un exécutable, alors la recherche dudit bug est plus difficile car tu n'as même plus le warning pour te guider …
C'est bien en C qu'une compilation sans erreurs n'est absolument pas le signe d'un programme sans erreurs, il ne faut jamais faire croire l'inverse aux débutants. Tu le sais aussi bien que moi, tu lis bon nombres de messages ici qui commencent par «mais ça compile sans erreurs et je ne vois pas où est l'erreur».

Il vaut mieux leurs (aux débutants) apprendre à utiliser un debuger, un profiler, à écrire des tests, bref une vraie méthode plutôt que de leurs conseiller un -Werror.
[...]

ou ici 

White Crow a écrit:

michelbillaud a écrit:

White Crow a écrit:

Comment peut-il débusquer une erreur s'il n'a pas d'exécutable à lancer afin de constater à quoi correspond (ou non) le choix de laisser passer un warning ?

Une erreur évitée, c'est une erreur qu'on n'a pas à chercher à l'exécution.

Et là se situe notre premier point de gros, énorme, 𝔨𝔬𝔩𝔬𝔰𝔰𝔞𝔩 désaccord : un warning n'est pas une erreur. Je suis d'accord avec toi concernant les erreurs. En revanche c'est une idiotie que de transformer tous les warnings en erreurs surtout si on demande en plus au compilo d'en afficher un maximum.

michelbillaud a écrit:

[...]

On a besoin de savoir faire tout ça pour débugger.

-

Edité par michelbillaud il y a environ 8 heures

Pour apprendre à debuguer (puisqu'on se restreint désormais aux débutants), il faut savoir lancer un debugger et avoir son (puisqu'on debugue souvent un code qui ne nous est pas inconnu) exécutable à débuger. Si en plus on a pas … je te raconte pas la galère. On repère rarement une fuite mémoire en scrutant le code … mais on remercie toujours valgrind ensuite de nous faire penser à écrire un nouveau test !

ou encore là où dès le 16 mars je te rappelai quand même que :

White Crow a écrit:

[...]

Le problème principal de -Werror est qu'il transforme un warning (définit par l'implémentation) en erreur (qui tient au standard). Tu peux du jour au lendemain te retrouver avec un programme qui ne compile plus car après un update de ton compilo tu as de nouveaux warnings … Le comportement n'est plus reproductible ce qui produit un programme un peu plus difficile à maintenir, car tu vas le patcher de plus en plus pour faire taire les warnings …

Et cela est carrément gênant pour un débutant qui compile ton code que tu as développé en gcc-6, et lui utilise gcc-8 qui produit de nouveaux warnings … etc etc 

Je t'assure c'est usant de devoir tout réécrire car tu ne suis pas et ne lis pas.

Je te propose, pour pouvoir faire avancer les choses, de relire toute la discussion, surtout mes propos a priori, pour mieux comprendre ce que je dis et ne pas penser répondre à une argumentation qui n'existe que dans ta tête pour plutôt reprendre celle que j'oppose à ta vision du monde qui semble meilleur avec le -Werror.

En fait , le problème, c'est que tu es convaincu que je n'ai pas lu ce que tu écris. En fait, c'est que je ne suis pas d'accord sur le fond, et ce n'est pas en répétant que j'ai mal lu, que je suis de mauvaise foi, que je ne connais rien à la "philosophie de c" etc que ça va avancer les choses.

Moi je trouve que tes raisonnements manquent cruellement de cas realistes. J'aimerais bien que tu montres des exemples concrets d'exercices pour débutants où

• L'elimination d'un warning ouvre la porte  à une "correction" foireuse mais plausible (pas genre  mettre la ligne en commentaires pour s'en debarrasser) qui serait difficile a retrouver ensuite.
• La compilation sous gcc x  d'un code destiné a des eleves, ecrit avec soin quelques années plus tôt, fasse apparaître des warnings qui posent réellement problème. (Improbable pour moi : je vérifie chaque année  avant de refiler du code)

(A l'occasion j'essaierai sur les sources que je donnais il y a une vingtaine d'années,  j'étais moins maniaque que maintenant. Le problème ça risque d'être la disparition de gets :-))

Ps, de nos jours, la philosophie moderne de la programmation, c'est de taper son code avec un IDE qui fait son possible (compilation à la volée, magie d'intellisense !) pour présenter en teemps reel (presque) une liste d'anomalies detectees. On peut donc les voir, et s'y interesser, au fur et à mesure. Ça raccourcit le temos de feedback, et ça réduit la charge cognitive (pas besoin de se remettre dans le contexte de ce qu'on voulait faire, puisqu'on n'en n'est pas sorti). Donc on corrige au plus vite , et on teste après.

-
Edité par michelbillaud 5 avril 2021 à 9:02:21

White Crow a écrit:

[...]

Le -Werror était peut-etre utile en C89 lorsque les messages du compilo étaient aussi abscons qu'une prophétie d'un oracle de Delphes. Ce qui aurait pu faire naître l'idée qu'un warning c'est une erreur mal diagnostiquée et qu'il fallait s'en débarrasser comme d'une sangsue quitte à utiliser un mégot de cigarette.

Mais on est un peu en 2021, les choses ont évoluées. Les compilos indiquent réellement un problème potentiel. Pas un problème qu'ils n'ont pas pu diagnostiquer comme une erreur, mais réellement un problème potentiel. Et pour t'en convaincre il suffit de lire la doc. Prends, par exemple, le manuel de gcc, liste les diagnostiques émis en utilisant -Wall -Wextra. Regarde les exemples donnés (oui, la doc est bien  faite). Prenons un exemple : -Wstring-compare qui est inclus dans -Wextra. Cette option émet un warning si au moment de la compilation gcc détecte qu'une comparaison où strcmp/strncmp intervient est constante et fausse. Est-cde une erreur dans le code ? ptêt, mais il existe des codes tout à fait valides pour qui cet avertissement n'est pas une erreur.

Que fais-tu pour la faire taire (parce que là il s'agit bien de faire taire un warning et non de corriger un bug potentiel) ? Ce que tu vas faire ne va-t-il pas impacter la détection de code mort ? N'aurait-il pas mieux valu laisser le code tel quel ?

Alors c'est clairement non : pas de -Werror surtout quand on utilise -Wall et -Wextra.

Mais bon, toi tu aimes bien, il y en a même qui utilisent -pedantic sur une base quotidienne par préférences.

White Crow a écrit:

[...]

Désormais, les compilateurs sont verbeux et diagnostiquent non seulement le code qu'on leur fournit mais aussi de plus en plus infèrent l'intention du programmeur. Il n'était pas concevable, ne serait-ce que 10 ans en arrière, d'imaginer qu'un compilo indiquerait ou une indentation qui semble fautive, ou une boucle sans corps dont il faudrait replacer le ; ou l'exemple avec le  strncat que je t'ai donné un peu plus haut.

[...]

Maintenant si tu veux un exemple bidon qu'on fournit aux débutants … allons-y pour un :

int my_strcmp(char *s1, char *s2)
{
	while (*s1 = *s2++)
		if (*s1++=='\0')
			return 0;
	return *s1 - *--s2;
}

char *my_strcpy(char *s1, char *s2)
{
	char *os1 = s1;
	while (*s1++ = *s2++);
	return os1;
}

void my_str_special_function(char *s1, char *s2)
{
	/* not implemented
}

Dans ce morceau de code il y a des erreurs et des warnings. Une compilation «normale» t'affiche :

$ gcc -Wall -Wextra tt.c -c
tt.c: In function ‘my_strcmp’:
tt.c:3:9: warning: suggest parentheses around assignment used as truth value [-Wparentheses]
    3 |  while (*s1 = *s2++)
      |         ^
tt.c: In function ‘my_strcpy’:
tt.c:12:9: warning: suggest parentheses around assignment used as truth value [-Wparentheses]
   12 |  while (*s1++ = *s2++);
      |         ^
tt.c: In function ‘my_str_special_function’:
tt.c:18:2: error: unterminated comment
   18 |  /* not implemented
      |  ^
tt.c:17:1: error: expected declaration or statement at end of input
   17 | {
      | ^
tt.c:16:36: warning: unused parameter ‘s1’ [-Wunused-parameter]
   16 | void my_str_special_function(char *s1, char *s2)
      |                              ~~~~~~^~
tt.c:16:46: warning: unused parameter ‘s2’ [-Wunused-parameter]
   16 | void my_str_special_function(char *s1, char *s2)
      |                                        ~~~~~~^~

Tu vois bien la différence entre warning et error. Car au risque de te surprendre une énième fois, il y a une différence. Comment un débutant corrigera-t-il ce code sans doute mal copié d'un cours ?

Avec ta méthode :

$ gcc -Wall -Wextra -Werror tt.c -c
tt.c: In function ‘my_strcmp’:
tt.c:3:9: error: suggest parentheses around assignment used as truth value [-Werror=parentheses]
    3 |  while (*s1 = *s2++)
      |         ^
tt.c: In function ‘my_strcpy’:
tt.c:12:9: error: suggest parentheses around assignment used as truth value [-Werror=parentheses]
   12 |  while (*s1++ = *s2++);
      |         ^
tt.c: In function ‘my_str_special_function’:
tt.c:18:2: error: unterminated comment
   18 |  /* not implemented
      |  ^
tt.c:17:1: error: expected declaration or statement at end of input
   17 | {
      | ^
tt.c:16:36: error: unused parameter ‘s1’ [-Werror=unused-parameter]
   16 | void my_str_special_function(char *s1, char *s2)
      |                              ~~~~~~^~
tt.c:16:46: error: unused parameter ‘s2’ [-Werror=unused-parameter]
   16 | void my_str_special_function(char *s1, char *s2)
      |                                        ~~~~~~^~
cc1: all warnings being treated as errors

Il y a les mêmes messages mais aucune distinction entre errors et warnings (puisqu'il n'y a plus de warning … logique). Il n'y a affiché que des erreurs …
Surtout les deux premiers warnings (enfin errors) ? un est une erreur l'autre non … le lazy student mettra-t-il des () comme recommandé partout ? un autre changera-t-il complètement sont code en corrigeant «l'erreur» ? Si ce n'est pas corrigé correctement, n'ayant plus aucune indications tangibles, le pauvre va s'arracher les cheveux, même avec un debugger.

Le pire c'est que le débutant n'apprendra jamais ce qu'est un warning car pour lui il n'y aura que des erreurs, même si certaines n'en sont pas.

J'ai à ce sujet plusieurs fois écrit :

White Crow a écrit:

michelbillaud a écrit:

White Crow a écrit:

Comment peut-il débusquer une erreur s'il n'a pas d'exécutable à lancer afin de constater à quoi correspond (ou non) le choix de laisser passer un warning ?

Une erreur évitée, c'est une erreur qu'on n'a pas à chercher à l'exécution.

Et là se situe notre premier point de gros, énorme, 𝔨𝔬𝔩𝔬𝔰𝔰𝔞𝔩 désaccord : un warning n'est pas une erreur. Je suis d'accord avec toi concernant les erreurs. En revanche c'est une idiotie que de transformer tous les warnings en erreurs surtout si on demande en plus au compilo d'en afficher un maximum.

michelbillaud a écrit:

[...]

On a besoin de savoir faire tout ça pour débugger.

-

Edité par michelbillaud il y a environ 8 heures

Pour apprendre à debuguer (puisqu'on se restreint désormais aux débutants), il faut savoir lancer un debugger et avoir son (puisqu'on debugue souvent un code qui ne nous est pas inconnu) exécutable à débuger. Si en plus on a pas … je te raconte pas la galère. On repère rarement une fuite mémoire en scrutant le code … mais on remercie toujours valgrind ensuite de nous faire penser à écrire un nouveau test !

michelbillaud a écrit:

En fait , le problème, c'est que tu es convaincu que je n'ai pas lu ce que tu écris. En fait, c'est que je ne suis pas d'accord, et ce n'est pas en répétant que j'ai mal lu, que je suis de mauvaise foi, que je ne connais rien à la "philosophie de c" etc que ça va avancer les choses.

Excuse-moi d'insister sur le fait que pour discuter avec toi il faille répéter les choses un minimum de 4 fois. Si je réécrit je montre également que je réécrit.

Mais j'explique aussi … comme dans le message précédent le tien :

White Crow a écrit:

[...]

Bon je vais simplement dessiner le cadre de ma pensée, tu pourras compléter en relisant mes messages … ok ?

• -Werror implique éliminer les warnings pour pouvoir disposer d'un exécutable ;
• éliminer les warnings n'incite en rien un débutant «à se pencher sur le warning pour le comprendre et le résoudre» (et même pas le cas échéant à cause de l'ineptie du «on traite les warnings comme des erreurs même si un warning n'est pas une erreur» ;
• le ebutant aura peut être modifié le code incorrectement ou inutilement ;
• le code peut planter (suite à l'introduction d'un UB par exemple) ;
• le débutant essayera de debuguer l'exécutable sans se souvenir ou sans avoir l'indication quelconque du warning mal corrigé par obligation  …
• le débutant se sent couillon de t'avoir écouté quand il se rend compte de tout cela.

Tout cela se re trouve dans mes commentaires précédents … 
[...]

Et si je mets l'accent sur ça ce n'est pas pour faire chier, c'est simplement en espérant que tu relises la discussion et que je n'ai plus besoin de me répéter …

Donc voilà tu as un exemple, en espérant que ce pourra être la première pierre d'une nouvelle discussion (tout en se souvenant de ce que j'ai pu écrire auparavant évidemment).

Je ne vois pas ce que tu espères, en prétendant que je ne connais pas la différence entre une erreur de compilation et un avertissement.  Tu tiens absolument à être insultant ?

> avec ta méthode il n'y a pas de distinction entre erreurs et warnings.

Bah, c'est parce que tu ne lis pas ce qui est écrit. A droite

      [-Werror=parentheses]

dit que si ça déclenche une erreur, c'est parce qu'on l'a demandé (-Werror=). Et si on l'a demandé, c'est parce qu'autrement ça ne le serait pas, logiquement.

> Le pire c'est que le débutant n'apprendra jamais ce qu'est un warning car pour lui il n'y aura que des erreurs, même si certaines n'en sont pas.

Bien sûr que si. Y a pas de "jamais". Parce que dans une phase ultérieure de son apprentissage, il aura certainement du code existant à bidouiller. C'est d'ailleurs ce que tu lui demandes de faire ensuite.

> Comment un débutant corrigera-t-il ce code sans doute mal copié d'un cours ?

D'un TRÈS MAUVAIS COURS. Ca fait des décennies qu'on déconseille très fortement de programmer dans ce style. Là clairement, il faut le foutre à la poubelle. Il faut éviter de montrer de code "pathologique" à des débutants, l'expérience montre qu'ils se sentent obligés de faire pareil "pour faire comme les grands". Et encore, tu ne nous a pas sorti les  premières versions en C, avec des gotos (source quelque part dans les oubliettes de Computer History Museum).

Mais bon, pour une correction superficielle, c'est marqué

1. strcpy "suggests assignment", or ce n'est n'est pas un. Voyons assignment, c'est affectation, donc ==

2. strcmp "suggests assignment", ça tombe bien c'est une "truth value". Donc pour différencier d'une affectation malencontreuse, on met des parenthèses ou mieux comparaison avec '\0'.

3. */pour fermer, ou  // ou mieux, écrire le code qui manque.

Y aurait eu le minimum syndical du C ANSI 89/90 , les const bien placés dans les paramètres auraient un peu arrangé les choses.

et donc, quel est le point là dedans ? En quoi ces corrections introduisent-elles des erreurs ?

Au passage, parce que l'enseignement ce n'est pas laisser les élèves se démerder, les deux premiers points sont l'occasion d'expliquer/rappeler

1. que l'affectation retourne une valeur

2. que la valeur nulle représente faux

3. quand dans les premiers temps d'unix, la technologie primitive laissait penser aux programmeurs qu'en écrivant de façon tordue, ils pouvait obtenir du code plus court que ce que fabriquerait le compilo avec du code "plan plan".

4. qu'on c'est vite aperçu que c'était une mauvaise approche de la programmation (et en plus, c'est faux), et qu'il faut favoriser la lisibilité. Un programmeur est là pour produire des codes sources, destinés à être maintenus.

---

Au fait, ton code préhistorique en C74 ne marche pas avec un codage 8 bits type isolatin.

char *s1 = "c";
char *s2 = "\251 (copyright en isolatin)";

if (my_strcmp(s1, s2) < 0) {
	printf("le caractère c vient avant (c)");
} else {
	printf("oups\n");
}

(compare avec le strcmp standard)

Et pas non plus en UTF8. Hint : unsigned char.

C'est peut être un exemple qu'on se refile de génération en génération dans certaines écoles, et ça dit quelque chose sur le sérieux de l'enseignement qui est dispensé (iso-8859, un standard depuis 1987...)

Tu n'aurais pas un exemple typique plus convaincant ?

-
Edité par michelbillaud 5 avril 2021 à 12:04:00

michelbillaud a écrit:

Je ne vois pas ce que tu espères, en prétendant que je ne connais pas la différence entre une erreur de compilation et un avertissement.  Tu tiens absolument à être insultant ?

> avec ta méthode il n'y a pas de distinction entre erreurs et warnings.

Bah, c'est parce que tu ne lis pas ce qui est écrit. A droite

      [-Werror=parentheses]

dit que si ça déclenche une erreur, c'est parce qu'on l'a demandé (-Werror=). Et si on l'a demandé, c'est parce qu'autrement ça ne le serait pas, logiquement.

Et à gauche … il n'y a que «error» dans ton cas … jamais de différence entre warning et error … jamais warning apparaît ⇒ tout est une erreur.

Mais bon tu dois avoir raison, un débutant saura certainement mieux que n'importe qui que «si à droite il y a un -Werror=prentheses c'est qu'à l'origine ce n'était qu'un warning qu'on a volontairement transformé en error» … désolé … je dois être particulièrement de mauvaise foi et vraiment borné et obstiné comme un manche de bois.

michelbillaud a écrit:

> Le pire c'est que le débutant n'apprendra jamais ce qu'est un warning car pour lui il n'y aura que des erreurs, même si certaines n'en sont pas.

Bien sûr que si. Y a pas de "jamais". Parce que dans une phase ultérieure de son apprentissage, il aura certainement du code existant à bidouiller. C'est d'ailleurs ce que tu lui demandes de faire ensuite.

Bien que ça ne provoque qu'un warning, pardon une erreur pour toi, le code :

char *my_strcpy(char *s1, char *s2)
{
    char *os1 = s1;
    while (*s1++ = *s2++);
    return os1;
}

ne contient AUCUNE ERREUR. Dois-je le crier pour que tu le comprennes ?

-Werror transforme un warning qui n'est pas une erreur qui ne pointe pas une erreur en erreur … 

Alors évidemment ce genre de warning peut pointer une erreur potentielle, comme dans l'autre cas … potentielle ; comme le montre ce code.

Alors qu'il y a ou non des fautes de style, des idiomes particuliers, tout ce que tu veux, cela montre que -Werror comme tu le suggères est une belle connerie.

Et puis tient, tant qu'on y est …

Le truc simple de débutant … mauvaise indentation et pas forcément volontaire hein  ou un étudiant qui utilise tab et un autre space pour l'indentation …  voire beautifier qui se prend les pattes dans le tapis …

char *my_strcpy(char *s1, char *s2)
{
	char *os1 = s1;
	while ( (*s1++ = *s2++) );
		return os1;
}

Tu te prends un warning en compilant →

tt.c: In function ‘my_strcpy’:
tt.c:4:2: warning: this ‘while’ clause does not guard... [-Wmisleading-indentation]
    4 |  while ( (*s1++ = *s2++) );
      |  ^~~~~
tt.c:5:3: note: ...this statement, but the latter is misleadingly indented as if it were guarded by the ‘while’
    5 |   return os1;
      |   ^~~~~~

Et là -Werror ? bah encore une fois de la daube.

Edit: suite à tes modifications dans ton message …

Tu voulais un exemple, tu en as un ⇒

Un code valide qui ne compile plus lorsqu'on utilise -Werror.

Et encore … c'est sans compter ce que je t'ai déjà donné comme exemple avec le strncat si je me souviens bien …

-
Edité par White Crow 5 avril 2021 à 12:12:30