Reputation: 83
I'm trying to compile the following code in gfortran:
INTEGER F(10),G(14),LUN(5)
DIMENSION MESSG(NMESSG)
DATA F(1),F(2),F(3),F(4),F(5),F(6),F(7),F(8),F(9),F(10)
1 / 1H( ,1H1 ,1HX ,1H, ,1H ,1H ,1HA ,1H ,1H ,1H) /
DATA G(1),G(2),G(3),G(4),G(5),G(6),G(7),G(8),G(9),G(10)
1 / 1H( ,1H1 ,1HX ,1H ,1H ,1H ,1H ,1H ,1H ,1H /
DATA G(11),G(12),G(13),G(14)
1 / 1H ,1H ,1H ,1H) /
DATA LA/1HA/,LCOM/1H,/,LBLANK/1H /
I get the following error:
Error: Expected a right parenthesis in expression at (1):
1 / 1H( ,1H1 ,1HX ,1H, ,1H ,1H ,1HA ,1H ,1H ,1H) /
1
The line referenced in the error is the fourth line of the code snippet. Anyone know what my problem is? I know this is really old code, but I inherited it in a scientific application and need to make it work.
Upvotes: 2
Views: 2834
Reputation: 29401
Your old code is using the Hollerith H to place character values into integer variables. Somewhat more modern Fortran could be:
character*10 F
DATA F / "(1X, A )" /
More modern:
character (len=10) :: F = "(1X, A )"
but these are changing the type of F, which would impact the rest of the code. So using these changes will require other rewrites, but if it were my code, I'd consider it, considering how archaic and unreadable the problem code section is. If that's too much work, I get the following to compile with gfortran:
program f2
INTEGER F(10),G(14),LUN(5)
DATA F(1),F(2),F(3),F(4),F(5),F(6),F(7),F(8),F(9),F(10)
$ / 1H( ,1H1 ,1HX ,1H, ,1H ,1H ,1HA ,1H ,1H ,1H) /
DATA G(1),G(2),G(3),G(4),G(5),G(6),G(7),G(8),G(9),G(10), G(11),G(12),G(13),G(14)
$ / 1H( ,1H1 ,1HX ,1H ,1H ,1H ,1H ,1H ,1H ,1H ,1H ,1H ,1H ,1H) /
DATA LA/1HA/,LCOM/1H,/,LBLANK/1H /
end
with
gfortran-mp-4.7 -O3 -ffixed-form -ffixed-line-length-none -std=legacy f2.f
Upvotes: 4
Reputation: 21441
The 1H
things are known as Hollerith constants from the Fortran 66 era, where the 1 indicates the length of the constant in terms of source code characters and then the actual value of the constant is the encoded form of that number of characters (including blanks) following the H. They are notoriously error prone.
Your code is using fixed form source. That is also notoriously error prone.
That said, after adjusting for the loss of the leading fixed form source columns your code compiles here with recent versions of gfortran. With Hollerith constants - all it takes is a blank out of position though - and things can break badly.
(Ironically, with fixed form source you can generally scatter blanks around with willful abandon - making the intersection of those two language features rather special...)
For what its worth, the encoded data for F and G looks like simple format specifiers. In "modern" Fortran (well, since 1977!) you would simply use character variables to hold the formats (1X,A)
and (1X)
(blanks elided) for F and G respectively. The other variables look like simple character constants (A
, comma and blank) - perhaps for use in building up a larger format specifier.
Bringing the code into at least the era of flares and strange colours would be pretty high on my list of priorities if I had to maintain it.
Upvotes: 2