Discussion :

[uriotcea]

Bonjour,

J'ai des centaines de message de warning à la compile à cause de l'attribue "warm_unused_result" qui me génére un warning pour toutes les fonctions standard non void. C'est agacant et les autres warning plus important sont noyés dedans.

Comment pourrais-je désactivé cette option?

[zul]

man gcc /warn_unused_result et tu aurai trouvé l'option qui va bien...

L'option en question c'est -Wno-unused-result. Et sinon c'est en général une mauvaise idée. La valeur de retour de ces fonctions indiquent si la fonction s'est bien passé ou pas, donc il est extrèmement important de le vérifier. De plus, si tu as des centaines de warning, ça tend à prouver que tu utilise trop l'api C, et pas assez d'abstraction C++.

[koala01]

Salut,

Cet avertissement te préviens que tu ne récupère pas la valeur des fonctions non void.

En toute logique, si une fonction renvoie quelque chose, c'est parce que la valeur retournée est... intéressante pour la fonction appelante, ne serait-ce que parce qu'elle représente la réussite ou la raison de l'échec de la fonction, ou parce que la fonction appelante a besoin de cette valeur pour travailler.

L'idéal serait donc, partout où cet avertissement survient, de veiller à effectivement récupérer la valeur de retour de la fonction et à gérer, au minimum, le cas de la réussite (qui permet de "faire la suite") et le cas général de l'échec

Ce type d'avertissement est occasionné par l'option -Wunused-return, qui est activée, entre autres, par l'options -Wunused, elle même activée -Wall (options valables pour Gcc-.

Tu peux donc envisager de désactiver ces avertissements en rajoutant (toujours sous Gcc) l'option -Wno-unused-result, mais, tu comprendra que je conseille fortement de plutôt choisir la première option, qui consiste à effectivement récupérer et gérer le retour de toutes les fonctions

[uriotcea]

Merci de vos réponses.
Effectivement j'ai enormément de fonction C tel "sscanf", "fget".
Le flag "Wno-unused_result" me va totalement en me suppriment tous ces warning.
Même si je suis conscient qu'ils peuvent avoir leurs utilité, ils n'était pas présent dans le gcc < 4.4.0.

[zul]

fgets peut être probablement facilement remplacer par getline.
sscanf par des ostringstream ou par des choses plus haut niveau, en fonction de la sémantique derrière (ça pourrait être remplacé par boost::serialization si il s'agit d'une opération de sauvegarde / lecture d'une structure).

De plus, il est franchement impossible d'utiliser sscanf sans vérifier la valeur de retour. Comment peux-tu savoir que ta ligne à matcher ce que tu attends si tu ne le vérifie pas ? Comment peux-tu être sûr par la suite de ne pas utiliser une variable non initialisé ?

De même, pour fgets, comment gère tu les fin de fichiers si tu ne lis pas le retour de la fonction (et je ne parle pas de tous les autres cas d'erreurs qui peuvent arriver). ?

Ces warning ne sont pas là pour "faire chier le monde", mais parce qu'il signale potentiellement des choses qui vont dans le future provoquer des comportements indéterminées. Donc, je répète, il serait bien mieux de les corriger, pas de les masquer (et même si gcc < 4.4.0 ne les indiquait pas, il n'est jamais trop tard pour corriger le code).

[Jean-Marc.Bourguet]

J'ai des centaines de message de warning à la compile à cause de l'attribue "warm_unused_result" qui me génére un warning pour toutes les fonctions standard non void. C'est agacant et les autres warning plus important sont noyés dedans.

-U_FORTIFY_SOURCE si j'ai bonne mémoire.

man gcc /warn_unused_result et tu aurai trouvé l'option qui va bien...

L'option en question c'est -Wno-unused-result. Et sinon c'est en général une mauvaise idée. La valeur de retour de ces fonctions indiquent si la fonction s'est bien passé ou pas, donc il est extrèmement important de le vérifier. De plus, si tu as des centaines de warning, ça tend à prouver que tu utilise trop l'api C, et pas assez d'abstraction C++.

C'est en théorie une très mauvaise idée d'ignorer ces warnings qui ne sont générés que pour des fonctions marquées comme devant les générér. Mais le problème est que la libc de GNU a marqué trop de choses, sous contrôle d'un ifdef, d'une part, et d'autre part que certaines distributions ont activé cet ifdef par défaut.

(et même si gcc < 4.4.0 ne les indiquait pas, il n'est jamais trop tard pour corriger le code).

C'est pas lié à la version de gcc (qui a ce mécanisme depuis la 3.4).

[uriotcea]

tout à fait d'accord, mais quand on a gérer un code de dizaines de millier de lignes, constiuté de c, cpp, fortran datant parfois de 20 ans, on fait au mieux pour que ca continu à fontionner et les belles ambitions de perfection sont passé au second plan.