Discussion :

[VITALTH]

Bonjour
J'ai remarqué un bug sur fortran 90 et 77 ( je ne sais pas si au dessus le problème est réglé ou non) en tout cas sur machine itanium

Suivant le code suivant :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
 
       PROGRAM ESSAI
 
       REAL VALF
       CHARACTER*1 VALC
 
       VALC='T'
       READ(VALF,*)VALC
 
 
 
       STOP
       END

Se faisant je m'attend à avoir une erreur d'instruction mais le formattage a réussi à se faire et je trouve la valeur -1 sur VALF

[Grame]

Bonjour

Se faisant je m'attend à avoir une erreur d'instruction mais le formattage a réussi à se faire et je trouve la valeur -1 sur VALF

Je ne sais pas sur quel OS tu travailles, ni avec quel compilateur, mais avec ma configuration (Linux fedora 16 + gfortran) j'ai évidemment un message d'erreur :

Code :

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

1
2
3
4
 
READ(VALF,*)VALC
     1
Error: UNIT specification at (1) must be an INTEGER expression or a CHARACTER variable

[VITALTH]

C'est bien ce que je pensais : surement un pb d'OS.
Pour info je travaille sur OpenVMS sur Machine Itanium

[Ehouarn]

Bonjour,

C'est bien ce que je pensais : surement un pb d'OS.

Non, comme l'indique Grame, c'est ton code Fortran qui est incorrect (mauvais arguments donnés au "read").

Bonne continuation

[VITALTH]

Je pense que tu ne m'as pas compris :
En fait j'aurais aimé avoir une erreur à l'execution mais le code continue comme s'il avait réussis la valeur "t" ou "T" dans une variable réel dont la valeur serait - 1. Et c'est ça qui n'est pas normal.

Sans entrer dans le détail on aurait plutot un code du type

Code :

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

1
2
3
4
5
6
7
8
9
10
 
       PROGRAM TEST
       REAL*4 VALF
 
C Demander à l'utilisateur la valeur réel
10    WRITE(*,'('' Entrer une valeur réel '',$)')
       READ(*,*,ERR=10)VALF
 
 
C Exploitation de VALF et suite ...

Je m'attends que si l'utilisateur tape "t" ou "T" il boucle sur la question et bien non et je retrouve -1 dans VALF. Et c'est ça qui est un problème d'OS

[Sylvain Bergeron]

Non.

Quand tu fais READ(VALF,*)VALC, tu essaies d'assigner la valeur qui est dans VALF (ou dans le fichier assigné à VALF) à la variable VALC. Et non le contraire. Je pense que tu voulais faire READ(VALC,*)VALF pour assigner "T" à VALF.

Ton compilateur (et non le OS) devrait crier pour l'erreur parce qu'un unit réel, ça n'a pas de sens. Il est également possible qu'il supporte une fonctionnalité obsolète (il y a très très très longtemps, avant l'invention des chaines de caractère (!), donc en F66 et en Fortran IV, les compilateurs supportaient la lecture internal sur des vecteurs servant de tampon...)

Si tu observe la valeur -1, c'est que ta variable n'a pas été initialisée. Le OS n'a rien à voir.

Finalement, la lecture en format libre n'offre pas le contrôle que tu cherches : si elle rencontre un caractère illégal, elle rejette la suite. Elle n'utilise donc que ce qui précède le "T". S'il n'y a rien, la variable sera inchangé.

[VITALTH]

Bonjour,
Oui tu as raison l'instruction est plutot :

READ(VALC,*)VALF

Désolé pour la faute de frappe.
C'est possible que ce soit un problème de compilateur.
Tout ce que je peux dire c'est que VALF a bien été initialisée, que le FORTRAN que j'utilise est le FORTRAN 77 avec certaines évolutions, que ce comportement bizarre ne fonctionne qu'avec la lettre "t" ou "T" et qu'avec les autres lettres, il y a bien une erreur à l'éxecution et que la chose la plus étrange c'est que si je renouvelle l'opération pour un string au lieu d'un caractère, le phénomène se reproduit pour n'importe quel string commençant par "t" ou "T".

[Sylvain Bergeron]

Alors, il reste la possibilité que le read voit "T" comme étant True. "F" fait quoi ?

[VITALTH]

Bonne idée je vais essayer

[VITALTH]

Ca marche avec "F"

"T" = -1
"F" = 0

[Ehouarn]

Bonjour,

C'est donc bien un problème de compilateur, ou plus précisément de la façon dont le compilateur gère une lecture avec un format "libre".

Le code que tu donnes ne pose pas de problème chez moi avec gfortran. Quel compilateur utilises-tu?

Il y a sinon éventuellement la possibilité de préciser le format de lecture, par ex:

Code :

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

1
2
 
       READ(*,"(G22.12)",ERR=10)VALF

Mais il y aura probablement toujours des possibles effets de bord (par ex: si l'uilisateur entre "D", cela sera interprété comme une erreur, mais si il entre "D2" cela sera interprété comme 0D2 donc VALF=0.)

[VITALTH]

Le compilateur ne te dira rien puisqu'il s'agit d'un fortran d'une machine VMS.
Moi même je ne connais pas son nom.

Personnellement je n'aime pas utiliser les formats libres pour des réponses attendues par des utilisateurs car on ne sait jamais ce qu'il va répondre et il faudra faire une ribambelle de test pour que la chaine attendue corresponde au format proposé

[Ehouarn]

Bonjour,

Le compilateur ne te dira rien puisqu'il s'agit d'un fortran d'une machine VMS.
Moi même je ne connais pas son nom.

OK, mais il y a probablement une doc qui pourrait être utile de consulter pour voir si il n'y aurait pas une option de compilation qui pourrait modifier ce comportement par défaut qui te gêne.

Personnellement je n'aime pas utiliser les formats libres pour des réponses attendues par des utilisateurs car on ne sait jamais ce qu'il va répondre et il faudra faire une ribambelle de test pour que la chaine attendue corresponde au format proposé

Pas sûr de comprendre ce que tu veux dire par là. c'est pourtant un format libre ( read(*,*)... ) que tu utilises actuellement, et je ne vois pas de ribambelle de tests se profiler dans le cas ou le format de lecture est du type que je propose, surtout si on voit "large" avec quelque chose du genre G26.16.

[VITALTH]

Bonjour,
Pour la doc je vais chercher ou peut être je contacterai le support HP.

Pour le format libre, j'ai du mal me faire comprendre : en fait je me méfie toujours de la solution où on cherche à caractériser le format numérique de l'utilisateur.

Je m'explique quelque chose du type :

Code :

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

1
2
 
READ(*,"(I1)",ERR=10)VALI

me donne pas confiance. Il suffit que l'utilisateur tape 10 et je ne récupère pas 10 mais 1.
Après j'avoue ne pas connaitre tous les formats : la plupart du temps j'utilise les "A", "I" et "F" (avec précision) mais je le fait surtout pour les "WRITE"

[Ehouarn]

Bonjour,

je me méfie toujours de la solution où on cherche à caractériser le format numérique de l'utilisateur

Oui, mais en voyant large sur le format de lecture (c.-a.d. en spécifiant un large nombre d'éléments potentiels à lire et un format 'G' qui combine les possibilités de 'F' et 'E'), on s'en sort généralement sans problèmes.

Ce n'est pas la panacée, en particulier si l'utilisateur entre un nombre délirant (qui dépasse les capacités du type de la variables) du genre 12345678901234567.890E234 , mais ce problème se pose de toute façon également avec un format libre.

[VITALTH]

Je comprends bien ce que tu veux dire. Ceci dit j'ai jamais test" l'inverse :
Imaginons :

Code :

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

1
2
 
READ(*,"(I2)",ERR=10)VALI

Et que l'utilisateur tape 1, je voudrais pas qu'il interprête ça comme 10.
Je testerai et je te tiendrai au courant : de même que la solution avec un format G et la variable "t" ou 'T'

[Ehouarn]

Bonjour,

Code :

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

1
2
 
READ(*,"(I2)",ERR=10)VALI

Et que l'utilisateur tape 1, je voudrais pas qu'il interprête ça comme 10.

Il ne faut pas confondre les comportements en lecture et écriture. Dans l'exemple que tu donnes, si l'utilisateur entre 1, alors on aura bien VALI=1 . Le I2 signifie là que l'on va lire un entier d'au maximum 2 chiffres, pas que l'utilisateur doit impérativement entre un entier de deux chiffres.
On aura par contre bien sûr un problème si l'utilisateur entre 123, ce qui mènera à VALI=12.