Précédence dans des COMMON ?

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.. :roll:

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

Soit 2 COMMON :

Code:

---

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:

---

1 2 3 4

subroutine TITI   include 'TOTO1' include 'TOTO2'

---

Si dans le corps de cette routine je trouve :

Code:

---

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

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

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".

Salut!

Citation:

---

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:

Citation:

---

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

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...)

juste pour vous tenir au courant ;)

et rajouter quelques horreurs possibles :roll:

ç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 !!!
:piou:

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

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

Citation:

---

Envoyé par 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

---

Voui, seulement les personnes connaissant l'algorithme sont depuis longtemps à la retraite.. :?

Et comme c'est une grande société nationale, il y a peu de chances qu'ils se sentent l'envie de revenir..

En fait, c'est le but de la manoeuvre : les auteurs sont partis.. Laissant le code.. Qui marche mais est incompréhensible et non maintenable..

Il faut donc reconstituer la connaissance complète du coeur du soft...

De plus, je suis le consultant du consultant... qui, même si il a fini par admettre quelques délais incompressibles (juste faire la liste des données en entrée/sortie du coeur m'a pris 6 semaines 1/2), avait signé son contrat il y a 6 mois sans savoir ce qu'il signait. Il a donc fait accepter des délais, mais comme je disais plus personne ne connait l'algorithme... Les règles générales oui.. Mais l'algo est ce qui marche et empêche à l'heure actuelle des dizaines de milliers de personnes de perdre la vie tous les jours...

Donc il faut au minimum le reproduire à l'identique...

Après qu'on sera certain à 100% que cela fait exactement la même chose, on pourra tenter de simplifier... et de modéliser un peu mieux...

J'ai quand même réussi à faire passer l'idée 1) de report de délai de 2 mois et 2) que 6 mois de tests est un minimum...

Citation:

---

Envoyé par Sylvain Bergeron

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

---

Non, mais je n'en ai pas eu le loisir .. Je te remercie du nom de l'outil, je le garde sous le coude.. :D

Là normalement ma partie devrait être terminée la semaine prochaine... Alors ma tête fait ce que doit faire (peut-être) ton outil...

En fait, le plus compliqué, avec ce que j'expliquais dans le post précédent, c'est d'arriver à suivre le cheminement... C'est même pas du spaghetti, c'est la Marmite-Mère de tous les spaghettis...:roll:


(petite note supplémentaire: certains commentaires disent l'inverse du code sur la même ligne !!!)

En fait, c'est à se demander si ce n'a pas été fait exprès, obfusqué pour que personne ne comprenne...

Citation:

---

Envoyé par souviron34

...petite note supplémentaire: certains commentaires disent l'inverse du code sur la même ligne !!!)...

---

Quoi ? Y-a des commentaires ? Tu nous fais perdre notre temps en demandant notre aide alors qu'il y a des commentaires ?