Discussion :

[bybby83]

Bonjour
J'ai récupéré un programme qui tournait sous HPUNIX et je doit le faire tourner sous Linux. Le programme ouvre un fichier et vient lire des valeurs dans celui.

l'ouverture du fichier :

Code :

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

1
2
3
4
5
6
7
      OPEN ( UNIT=IUNIT,
     %          FILE=AC_NOM_FICHIER,
     %          ACCESS='SEQUENTIAL',
     %          FORM='UNFORMATTED',
     %          CONVERT='SWAP',
     %          STATUS='OLD',
     %          IOSTAT=IOS )

L'ouverture du fichier se passe très bien, j'ai IOS=0 en sortie.

Première lecture :

Code :

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

1
2
INTEGER*4 INFOS_ENREG(7)
READ (IUNIT,IOSTAT=IOS) INFOS_ENREG(1), INFOS_ENREG(2)

La premère lecture se passe bien, j'ai IOS=0 en sortie.
Deuxième lecture

Code :

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

READ (IUNIT,IOSTAT=IOS) INFOS_ENREG(3), INFOS_ENREG(4)

La deuxième lecture pose problème, j'ai IOS=-1 en sortie.
Je ne comprends pas pourquoi.

Je n'ai jamais fais de FORTRAN avant, je compile avec gcc.
Si quelqu'un peut m'aider merci.

[genteur slayer]

déjà, si tu compile avec gcc, en fait il va appeler f2c (qui converti ton fichier fortran en C) puis appelé gcc pour compiler ce code... cette methode marche mais elle est vraiment très sale, je te conseille déjà d'utiliser gfortran (compilateur basé sur gcc mais qui ne fait pas de convertion de language donc plus propre)

ensuite est-tu sûr que ton fichier est bien propre en particulier en ce qui concerne le caractère de fin de ligne... j'ai des problème de ce genre entre des fichier windows/MAC/Unix qui ont des caractères de fin de ligne différents et donc cela met le bordèle à la lecture...

si ton code n'est pas du F77 mais au moins du fortran90, tu peux rajouter dans ton open un POSITION='rewind' forçant le pointeur de fichier à être à son début...

(à vérifié) mais il me semble que le ios=-1 signifie qu'il est arrivé à la fin du fichier... à chaque nouveau read, tu passe à la ligne suivante

[bybby83]

J'ai esseyé de compiler avec gfortran, mais j'ai toujours la même chose.
De plus, la première instruction que je lit n'est pas vraiment la première.
Mon fichier commence par :
00000008 00000001 00000017 00000008
Quand je fais un READ (IUNIT,IOSTAT=IOS) INFOS_ENREG(1), INFOS_ENREG(2)
j'ai INFOS_ENREG(1) = 23 = 17hex
et INFOS_ENREG(2) = 8, et ceux même en utilisant le POSITION='rewind'
INFOS_ENREG(1) et INFOS_ENREG(2) sont des INTEGER*4
Mon fichier est un fichier binaire, il n'y a pas de caractere de fin de ligne.
Merci de ton aide

[Sylvain Bergeron]

...Mon fichier commence par :
00000008 00000001 00000017 00000008
Quand je fais un READ (IUNIT,IOSTAT=IOS) INFOS_ENREG(1), INFOS_ENREG(2)
j'ai INFOS_ENREG(1) = 23 = 17hex
et INFOS_ENREG(2) = 8, et ceux même en utilisant le POSITION='rewind'
INFOS_ENREG(1) et INFOS_ENREG(2) sont des INTEGER*4
Mon fichier est un fichier binaire, il n'y a pas de caractere de fin de ligne...

Pour que ça soit clair, ton fichier n'est pas binaire, il est sequential unformatted. Le fichier n'est pas pure binaire au sens où il est structuré (j'exclus ici le fait qu'au sens strict, tout fichier informatique est binaire...).

Le problème auquel tu fais face est que cette structure n'est pas définie par le standard. Ce dernier défini la fonctionnalité, non l'implantation physique. En pratique, les fichiers sequential unformatted respectent souvent la structure suivante :

• Longueur du premier enregistrement
• Données (binaire) du premier enregistrement
• Longueur du premier enregistrement (encore)
• Longueur du deuxième enregistrement
• Données du deuxième enregistrement.
• ...

Toutes ces informations sont en binaire (par opposition à texte). La longueur peut représenter le nombre d'octets ou de mots ou de champs de 32 bits. En regardant l'extrait de fichier que tu fourni, on peut supposer que le premier enregistrement est :

• 00000008 (longueur des données en octets)
• 00000001 00000017 (données)
• 00000008 (longueur des données)

Ton programme devrait alors lire 1 dans INFOS_ENREG(1) et 23 dans INFOS_ENREG(2). S'il lit 23 et 8, c'est qu'il «saute» le 00000001. Il est plus probable à mon avis que ton programme considère que les longueurs sont codées en 64 bits. Il «voit» alors que le premier enregistrement a une longueur de 34 359 738 369. Il y a alors un EOF (ioStat=-1) à la lecture du 2ème enregistrement...

Tu devrais lire le manuel de ton compilateur pour t'assurer que l'interprétation est bonne et pour voir si une switche existe pour contourner le problème. Sinon ? Il te faudrait recréer le fichier dans un format compatible avec ton compilateur, ou le lire en vrai binaire (stream) pour le convertir. Il est parfois possible de contourner en lisant en binaire direct...

[genteur slayer]

est-ce que tu sais comment est écrit le fichier que tu lit?

moi je fait des écriture sytle:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
program test
 
  integer L,H
  real(kind=8)temps
 
  L=10
  H=15
  temps=2.5d0
  open ( unit = 11,                  &
         file = "toto.hex",      &
         form = "unformatted",        &
         access = "sequential",      &
         action = "write",           &
         position = "rewind",        &
         status = "unknown",         &
         iostat =ios)
  write (11) L, H, temps
  close(11)
 
end program test

le fichier qui a été généré est de la forme:

Code :

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

1
2
3
 
10 00 00 00 0a 00 00 00 0f 00 00 00 00 00 00 00 00
00 00 04 40 10 00 00 00

je suis sous cygwin, avec gfortran et il semble que les octets sont "à l'envers":

10000000 0a000000 0f000000 0000000000000440 10000000

j'ai donc une séquence d'entrée et de sortis des données, mes deux entier et mon réél...

cela dit tu as peut-être un problème de format des données si ton prog attend 0a000000 et que tu lui donne 0000000a il risque de pas comprendre et d'interprèter de travers....

donc regarde bien comment a été écrit ton fichier d'entrée!

[bybby83]

Merci pour vos réponse
Mon fichier a été écrit en big-endian, et je le lis en big-endain, c'est grâce à l'option convert='SWAP'.
Mon fichier est écrit de la façon suivante :
1er mot = Type d'info
2 ième mot = longueur de la données en mot (x mots)
x mots = données
1er mot = type d'info
...
Pour l'instant je n'ai pas avancé, j'en suis toujours au même point

[bybby83]

J'ai fait la même manipulation, j'ai créé un fichier avec dedans 10, 15 et 2.5. J'ai eu le même fichier
10 00 00 00 0a 00 00 00 0f 00 00 00 00 00 00 00 00
00 00 04 40 10 00 00 00.
Ensuite j'ai essayer de le relire et je suis retomber sur 10, 15 et 2.5.
J'ai inséré ce code dans le code principal qui lit l'autre fichier.

Par curiosité, j'ai exécuté ceci

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
         L=10
          H=15
          temps=2.5d0
          OPEN ( unit = 11,
     %          file = "/lv001/thetis/toto2.hex",
     %          form = "unformatted",
     %          access = "sequential",
     %          action = "read",
     %          position = "rewind",
     %          status = "old",
     %          iostat =ios)
          write (11) L
          write (11) H
          write (11) temps
          close(11)

toto2.hex vaut :
04000000 00000000 0A000000 04000000 00000000 04000000 00000000 0F000000 00000000 08000000 00000000 00000000 00000440 08000000 00000000

Dans les deux cas, la relecture effectuée comme l'écriture se passe bien.

Je ne comprends pas pourquoi les fichiers sont différents.