0

Within some legacy Fortran 77 subroutines I was using the continuation mark & in position 6 and few cpp directives to adjust I/O at compile time - depending on very few parameters - to avoid redundancy. Look at a simpler example, here below:

      open(unit=1,file=opfile,status="unknown",form="unformatted")
!                                                          
      read(1) a, b, c        
!
#ifdef _READMORE                                             
     &       ,d, e                                        
#endif                                                        
!                                                             
      close(1)

Now, after some f90 refactoring (basically, putting almost everything within modules), I am struggling to reproduce the above mentioned behaviour, i.e. reading d and e if and only if _READMORE is defined, since the first solution I tried - the one here below - does not work as expected, because of the unexpected & at the end of the first line, if _READMORE is not defined:

open(unit=1,file=opfile,status="unknown",form="unformatted")
!                                                          
  read(1) a, b, c &        
!
#ifdef _READMORE                                             
         ,d, e                                        
#endif                                                        
!                                                             
close(1)

Could anyone suggest me what would be the best way to accomplish this task?

It would be appreciable if the proposed solution still relies on this continuation line trick and preserves backward compatibility.

andreagalle
  • 620
  • 6
  • 17
  • As you can see I have also tried to add a comment line, below the `&` continuation line (just in case `_READMORE ` was not defined), but as expected this is ignored. Anyway, it wouldn't be advisable a solution depending on a comment line! XD – andreagalle Jun 27 '20 at 16:19

2 Answers2

1

I would go for the explicit version:

open(unit=1,file=opfile,status="unknown",form="unformatted")
!                                                          
!
#ifdef _READMORE                                             
  read(1) a, b, c &        
         ,d, e                                        
#else
  read(1) a, b, c
#endif                                                        
!                                                             
close(1)
albert
  • 8,285
  • 3
  • 19
  • 32
  • Thanks, probably this is the best compromise, adding just a little repetition (for the sake of readability, for sure). Although, it seems to me less doable when you have couple (or three) `#ifdef` as I actually have (even if I didn't mentioned it, here above). To take into consideration all the possible `#ifdef` and `#ifndef` combinations rapidly becomes a nightmare...imagine what a mess it would be with nested ones! – andreagalle Jun 27 '20 at 16:53
  • Another option (not really nice) would be to have the files that need these kind of constructs as "fixed form Fortran" and the others as "free form Fortran". A nice sentence in the Fortran standard is "It is a simple matter for a software tool to convert from fixed to free form source." ... – albert Jun 28 '20 at 08:42
  • You are probably right @albert, I was wondering in fact why there are so many legacy fixed form FORTRAN files, still around! Could I put such (fixed form FORTRAN) subroutines within a module (namely .F90 files) or these requires the free form standard? – andreagalle Jun 28 '20 at 08:55
  • No it is not allowed to mix free and fixed formatted code (wold also be a nightmare for a reader and a compiler). – albert Jun 28 '20 at 09:14
  • Using -fixed is required, and I can only seem to get -D-lines working when I use -fixed... (on ifort) – Holmz Jun 28 '20 at 21:37
  • 1
    @Holmz -fixed is required for what? What’s about -D-lines? – andreagalle Jun 30 '20 at 09:33
  • @andregalle -fixed required for a .f90 to be interpreted as fixed form. D lines are generally helpful in the earlier debugging stages. I mention that as it is somewhat related (and somewhat orthogonal) to where the continuation happens. The preceding comment about mixing fixed and free form prompted the response that sometimes people may want a -fixed form when using f90 or later... so the legacy f77 code would not need to be totally redone for free form, if it was updated for say modules, etc, and then got a .f90 suffix... providing that you added -fixed to the compile arguments. – Holmz Jul 01 '20 at 22:38
  • @Holmz The question of @andregalle was, in my opinion, whether he could have a fixed formatted subroutine in a module that further is free formatted and this is not possible. Inside a project it is possible to have separate fixed formatted and free formatted file and with the `-free` / `-fixed` (or similar options) one can steer / fine tune the way a file is compiled. – albert Jul 02 '20 at 07:54
  • Yeah @albert the comment was more for avoiding a complete restructure to f90 AND freeform... one can go to F90+ and still use -fixed as an easier transition to upgrading and modernisation. – Holmz Jul 04 '20 at 02:38
0

The only workaround I found - thus far - is simply adding one more read statement (coming together with many side effects):

open(unit=1,file=opfile,status="unknown",form="unformatted")
!                                                          
  read(1) a, b, c
!
#ifdef _READMORE                                             
  read(1) d, e                                        
#endif                                                        
!                                                             
close(1)

avoiding at all the continuation line trick above. However, if I am not wrong, this would fail reading files written by the original Fortran 77 subroutine, when _READMORE is defined, since each read/write statement adds a newline:

      open(unit=1,file=opfile,status="unknown",form="unformatted")
!                                                          
      write(1) a, b, c        
!
#ifdef _READMORE                                             
     &        ,d, e                                        
#endif                                                        
!                                                             
      close(1)

and unfortunately I have a lot of these files that I would not like to re-write all them this way.

andreagalle
  • 620
  • 6
  • 17
  • 1
    Your first example would result in reading 2 lines and probably not the intended one line reading. – albert Jun 27 '20 at 16:35
  • Yes, you are right, that’s why this workaround has not the backward compatibility I was looking for!... – andreagalle Jun 27 '20 at 17:46