Version imprimable
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:
2
3
4
5
6
7
8
9
10
11
12
13PROGRAM 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
Bonjour
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 :Citation:
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
Code:
2
3
4
C'est bien ce que je pensais : surement un pb d'OS.
Pour info je travaille sur OpenVMS sur Machine Itanium
Bonjour,
Non, comme l'indique Grame, c'est ton code Fortran qui est incorrect (mauvais arguments donnés au "read").Citation:
C'est bien ce que je pensais : surement un pb d'OS.
Bonne continuation
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
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'OSCode:
2
3
4
5
6
7
8
9
10PROGRAM 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 ...
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é.
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".
Alors, il reste la possibilité que le read voit "T" comme étant True. "F" fait quoi ?
Bonne idée je vais essayer
Ca marche avec "F"
"T" = -1
"F" = 0
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:
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.)Code:
2READ(*,"(G22.12)",ERR=10)VALF
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é
Bonjour,
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.Citation:
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.
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.Citation:
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é
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 :
me donne pas confiance. Il suffit que l'utilisateur tape 10 et je ne récupère pas 10 mais 1.Code:
2
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"
Bonjour,
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.Citation:
je me méfie toujours de la solution où on cherche à caractériser le format numérique de l'utilisateur
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.
Je comprends bien ce que tu veux dire. Ceci dit j'ai jamais test" l'inverse :
Imaginons :
Et que l'utilisateur tape 1, je voudrais pas qu'il interprête ça comme 10.Code:
2
Je testerai et je te tiendrai au courant : de même que la solution avec un format G et la variable "t" ou 'T'
Bonjour,
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.Citation:
Envoyé par VITALTH
On aura par contre bien sûr un problème si l'utilisateur entre 123, ce qui mènera à VALI=12.