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.