Discussion :

[souviron34]

Bonjour

Je vous expose le problème..

Je travaille sur un très gros code (industriel ET critique (vies de milliers de personnes en jeu)), écrit entre il y a 27 ans et il y a 6 ans.

Ses auteurs auraient pu écrire "Le Guide des Mauvaises Pratiques en Fortran".. :

• noms de variables cryptiques
• noms de fonctions cryptiques
• nom de modules cryptiques
• aucun commentaire (en entête) des routines sur leur but
• aucun commentaire (en entête) des routines sur les entrées/sorties
• usage plus qu'abusif du goto (toutes les 5 lignes)
• API des routines réduite au minimum (un paramètre d'entrée (cas) et un paramètre de sortie (code d'erreur)), tout se passant par COMMON
• découpage non fonctionnel des fichiers
• usage de variables locales portant le même nom que des variables de COMMON
• et (j'ai gardé le meilleur pour la fin ) usage de variables portant le même nom dans des COMMON différents...
• combinaison des 2 derniers points..

C'est précisément sur ce cas que je demande votre aide..

Soit 2 COMMON :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
COMMON / TOTO1 / A, B, C, VAR1, D, E, F

COMMON / TOTO2 / G, H, I, K, L, VAR1, M, N

Soit une routine contenant ces 2 COMMON :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
subroutine TITI 
 
include 'TOTO1'
include 'TOTO2'

Si dans le corps de cette routine je trouve :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
if ( VAR1 .eq. 1 ) then
   VAR1 = 2
end if

Que se passe-t-il ?

Je ne pense pas que cela prenne ou affecte les 2 en même temps (si elles ne sont pas au même décalage dans les COMMON).

Laquelle est prise pour le test ? pour l'affectation ?

Est-ce celle du premier COMMON ? du dernier ?

Je sollicite votre expertise..

Mais s'il vous plaît, au vu de la criticité du code, je ne souhaiterais que des réponses réelles, de gens qui connaissent la réponse, pas des hypothèses..

(je vais la jouer "Qui veut gagner des millions" : "ne répondez que si vous savez" )

Merci

[Leflix]

Salut Souviron,

En fait c'est tres simple et la question (que tu poses) ne se pose en fait meme pas, car dans la norme fortran classique, une meme variable ne peut pas etre definie dans 2 common differents. Je ne suis pas un pro du f90 mais je ne pense pas que cela soit possible non plus.
C'est justement a mon avis pour eviter le genre de probleme que tu souleves.
Donc si tu compiles ton programme tu devrais voir apparaitre un message a la compilation du genre:

ERROR: line ( ) variable cannot be in common twice

Donc je te suggere de remedier rapidement a cela , en enlevant d'un de ces common la variable VAR1

Comme je l'ai deja dit une fois, c'est a cause de programmeurs comme cela que fortran jouit d'une si mauvaise reputation dans la communaute des informaticiens...
On peut tres bien ecrire un programme sans un seul GO TO

[genteur slayer]

et bien déjà, je te souhaite bon courrage!!! je suis passé par là il y a quelques mois (sur un code plus petit que le tiens je suppose) et je comprend la merde!!!!

pour tes common, je suis étonné que le compilateur ne t'ai pas envoyer chié à causse de cette doube définition...

sinon, j'aurai tendance à dire que c'est le dernier déclaré qui prend le pas sur l'autre. dans ton exemple, je dirai que c'est le Var1 du toto2.

cela dit il est possible que ce soit la lotterie si ton compilo n'est pas "propre".

[FR119492]

Salut!

Mais s'il vous plaît, au vu de la criticité du code, je ne souhaiterais que des réponses réelles, de gens qui connaissent la réponse, pas des hypothèses..

Désolé, mais je ne peux pas faire mieux que ce qui suit:
Je lis dans mon manuel de Compaq Fortran:

A variable can appear in only one common block within a scoping unit.

Or ton code semble ne pas obéir à cette règle; il risque donc de faire n'importe quoi!
A mon avis, tu n'as pas d'autre possibilité que de bidouiller quelques tests, comme par exemple afficher les valeurs des variables homonymes immédiatement avant l'appel d'une routine, puis la valeur de la variable dans la routine elle-même.

Comme quoi on réserve les problèmes les plus merdiques aux programmeurs les plus expérimentés. Bien du courage!
Jean-Marc

[Sylvain Bergeron]

Salut Sauvignon,

J'ai testé sur 2 compilateurs (Intel et Lahey). Les 2 refusent. Si j'extrapole la réponse de Jean-Marc, Compaq refuse également.

Comme d'autres l'on dit, ton code n'est pas standard. Techniquement, ça veut dire que ce n'est pas du Fortran... Si un compilateur le supporte effectivement, alors il peut bien faire ce qu'il veut...

Ceci dit, tu as 2 solutions : tu corriges le code, ou tu mets une copie du SE et du compilateur sous voute dans un coffret de sureté parce que tu ne pourras jamais migrer ce code... De mon expérience avec de tels programmes, je te suggère de mettre également du matériel sous voute au cas où le SE ou le compilateur ne fonctionne pas sur du matériel futur...

(Nous avons un système ici ne fonctionnant que sur des PC DOS 486 i.e. ça ne fonctionne pas dans une fenêtre DOS ou CMD depuis Win95, et ça ne fonctionne pas sur un Pentium ! Une équipe est à réécrire le programme. Tout doit être prêt avant que notre dernier 486 rende l'âme...)

[souviron34]

juste pour vous tenir au courant

et rajouter quelques horreurs possibles

ça avance..

Une des 2 parties est finie, l'autre est en cours. J'essaye juste de déterminer l'algorithme.. et c'est coton...

Alors quelques usages supplémentaires d'horreurs, et quelques participations supplémentaires à "Tout ce qu'il ne faut pas faire"...

1. usage extensif des "alternate return"
   
   
2. goto directement vers une branche d'un if..else..endif
   
   
3. goto directement de l'intérieur d'une branche d'un if vers une boucle
   
   
4. boucles sans DO ou FOR, juste des GOTO
   
   
5. boucles imbriquées avec la syntaxe ci-dessus
   
   
6. appels "récursifs" de routines grâce aux "alternate returns"
   
   
7. goto directs de l'intérieur d'une boucle vers une boucle 3 niveaux plus haut
   
   
8. et j'en passe encore quelques unes....

Depuis 3 jours je suis sur une routine de 2000 lignes comme ça, et j'ai du mal à schématiser ce qu'elle fait !!!

[FR119492]

Salut!
Juste un point de vue de retraité. Retravailler un code aussi gigantesque et mal foutu que le tien semble l'être me semble être du temps perdu. A ta place, j'essaierais de faire comprendre au "client" combien la situation est désespérée et le persuader que, s'il veut vraiment un programme qui fonctionne, il n'a pas d'autre solution que de te fournir tous les algorithmes utilisés et de te mandater pour tout reprogrammer à partir de zéro. Comme quoi le métier de développeur, ce n'est pas seulement d'écrire du code, mais aussi de la diplomatie et de la persuasion.
Jean-Marc

[Sylvain Bergeron]

As-tu essayé avec certains outils genre unspag, ou certains convertisseurs de f77 à f90 ou 95 ?