remise à niveau de code antique

Le
Ronounours
Bonjour,

Une partie de mon boulot consiste à assurer la maintenance de
quelques applis anciennes dans des environnements pas tous
jeunes (certains clients ont commencé en 2010 à planifier
pour 2012 la migration AIX 4.3 vers AIX 5.2)

Dans le tas, il y a une partie de programmes en C++, qui ont
majoritairement plus de 10 ans, qui n'ont subis depuis que
des corrections ou évolutions mineures.

Comme j'avais un peu de temps, j'ai recompilé pour voir un
de ces progs avec g++ récent (4.4 pour être précis).

Une fois passé les premiers obstacles (pourquoi diable j'ai
du rajouter des includes de stdio.h, string.h et quelques
autres partout alors que précédemment ça passait très bien
sans ?) j'ai des milliers de lignes de warnings abscons
deprecated conversion from string constant to 'char*'
ou carrément à la con
suggest parentheses around '&&' within '||'
(je suppose que c'est pour le cas ou le développeur ait
du mal avec les règles de priorités)

Je sais parfaitement que le langage a évolué, que les
compilateurs ont progressé, notamment en ce qui concerne
les optimisations, et que certaines constructions jadis
légales sont maintenant dangereuses mais comment repérer
les warnings pertinents dans ce fouillis pour espérer les
corriger ?

Pour parodier un truc connu : trop de warnings tuent les
warnings.

Comment on fait ? On filtre avec grep ? On joue avec
des options ou des pragma ?
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Alain Ketterlin
Le #23122531
Ronounours
[...]
Comme j'avais un peu de temps, j'ai recompilé pour voir un
de ces progs avec g++ récent (4.4 pour être précis).

Une fois passé les premiers obstacles (pourquoi diable j'ai
du rajouter des includes de stdio.h, string.h et quelques
autres partout alors que précédemment ça passait très bien
sans ?)



Tu veux sûrement parler de cstdio, cstring...

j'ai des milliers de lignes de warnings abscons deprecated conversion
from string constant to 'char*' ou carrément à la con suggest
parentheses around '&&' within '||' (je suppose que c'est pour le cas
ou le développeur ait du mal avec les règles de priorités)



Le premier est à corriger absolument, juste pour voir si personne ne
s'amuse à écrire dans la chaîne. Le second est à corrig er absolument,
juste pour le mec qui fera la prochaine migration.

Je sais parfaitement que le langage a évolué, que les compilate urs ont
progressé, notamment en ce qui concerne les optimisations, et que
certaines constructions jadis légales sont maintenant dangereuses ma is
comment repérer les warnings pertinents dans ce fouillis pour espà ©rer
les corriger ?



Je ne connais pas de warning non-pertinent. Mais tu en auras peut-être
venant de fichiers dont tu n'es pas maître.

Pour parodier un truc connu : trop de warnings tuent les warnings.



Un seul warning négligé peut tuer ton appli.

Comment on fait ? On filtre avec grep ? On joue avec des options ou
des pragma ?



On compile avec -Wall -Wextra -O3 (ou -O2, en tout cas on branche les
optimisations, ça permet d'avoir plus de warnings), et si on a la pà ªche
on ajoute -pedantic.


Si vraiment ça te fait beaucoup de warnings, utilise un IDE qui parse la
sortie du compilo pour te les indiquer dans le source (j'utilise flymake
dans emacs, mais j'imagine qu'il doit y avoir d'autres solutions).

-- Alain.
Marc
Le #23123451
Ronounours wrote:

Une fois passé les premiers obstacles (pourquoi diable j'ai
du rajouter des includes de stdio.h, string.h et quelques
autres partout alors que précédemment ça passait très bien
sans ?)



Parce qu'avant des tas de headers incluaient des tas d'autres headers
inutilement, et que quelqu'un a fait le ménage entretemps.

j'ai des milliers de lignes de warnings abscons
deprecated conversion from string constant to 'char*'
ou carrément à la con
suggest parentheses around '&&' within '||'
(je suppose que c'est pour le cas ou le développeur ait
du mal avec les règles de priorités)



Le premier warning est assez clair, même si c'était toléré par le
passé, on n'a pas le droit d'écrire :
char* s="bonjour";
Il faut écrire à la place :
const char* s="bonjour";
ou, si on veut écrire dedans ensuite :
char s[]="bonjour";

Le second warning me semble être une bonne pratique. Mais on peut
toujours l'enlever avec -Wno-parentheses (un gcc récent précise à côté
de chaque warning l'option correspondante).

Il y a des warnings beaucoup plus discutables que ces deux-là...

Je sais parfaitement que le langage a évolué, que les
compilateurs ont progressé, notamment en ce qui concerne
les optimisations, et que certaines constructions jadis
légales sont maintenant dangereuses mais comment repérer
les warnings pertinents dans ce fouillis pour espérer les
corriger ?



On peut faire plus sélectif que -Wall, qui est simplement une bonne
base pour la majorité des utilisateurs, mais peut être adapté par
chacun.
Ronounours
Le #23124021
Bonjour,


Le 13/02/2011 21:46, Marc a écrit :
Ronounours wrote:

Une fois passé les premiers obstacles (pourquoi diable j'ai
du rajouter des includes de stdio.h, string.h et quelques
autres partout alors que précédemment ça passait très bien
sans ?)



Parce qu'avant des tas de headers incluaient des tas d'autres headers
inutilement, et que quelqu'un a fait le ménage entretemps.



Oui, probablement. ce qui me choque un brin, c'est la non
compatibilité ascendante. Dans mon boulot c'est très
important de ne pas casser une configuration qui marche.
Mais tant pis, je peux vivre avec.

j'ai des milliers de lignes de warnings abscons
deprecated conversion from string constant to 'char*'
ou carrément à la con
suggest parentheses around '&&' within '||'
(je suppose que c'est pour le cas ou le développeur ait
du mal avec les règles de priorités)



Le premier warning est assez clair, même si c'était toléré par le
passé, on n'a pas le droit d'écrire :
char* s="bonjour";
Il faut écrire à la place :
const char* s="bonjour";
ou, si on veut écrire dedans ensuite :
char s[]="bonjour";



Alors là, merci. Je m'étais tellement polarisé sur deprecated
conversion que j'avais même pas une seconde pensé à ça.

Le second warning me semble être une bonne pratique. Mais on peut
toujours l'enlever avec -Wno-parentheses (un gcc récent précise à côté
de chaque warning l'option correspondante).



Et hop, dans le makefile.

Il y a des warnings beaucoup plus discutables que ces deux-là...



Je sais pas lesquels, peut-être quand on modifie une zone
mémoire en utilisant un pointeur ? Des fois qu'il contienne
une adresse invalide. On sait jamais.

Et puis aussi au début de chaque compil, un truc du style
"vous compilez un programme C++, il pourrait contenir des
bugs, vous préférez pas coder en ...." ?

Non, non, les priorités sont définies, et à moins de faire
de l'obfuscated, il n'y a pas besoin de parenthèses inutiles.
Marc
Le #23124181
Ronounours wrote:

Oui, probablement. ce qui me choque un brin, c'est la non
compatibilité ascendante. Dans mon boulot c'est très
important de ne pas casser une configuration qui marche.



Il y a des limites à cela. La seule façon de ne rien casser est de ne
rien changer. Si ils gardent la compatibilité binaire et qu'il suffit
d'ajouter quelques #include évidents pour la compatibilité des
sources, ça me semble très acceptable.

Non, non, les priorités sont définies, et à moins de faire
de l'obfuscated, il n'y a pas besoin de parenthèses inutiles.



Je dirais que justement c'est ne pas mettre les parenthèses qui est de
l'obfuscated, mais à chaque projet ses conventions.
Fabien LE LEZ
Le #23124271
On Mon, 14 Feb 2011 07:22:54 +0100, Ronounours :

Parce qu'avant des tas de headers incluaient des tas d'autres headers
inutilement, et que quelqu'un a fait le ménage entretemps.



Oui, probablement. ce qui me choque un brin, c'est la non
compatibilité ascendante.



Le fait pour un code de ne pas inclure les headers dont il a besoin
(d'après la norme, pas en essayant au hasard) est un bug.
Si une vieille version de g++ acceptait ça, c'était également un bug.
Le deuxième bug a été réparé dans g++ ; il ne te reste plus qu'à
réparer le premier dans ton code.
Publicité
Poster une réponse
Anonyme