Help!! end-of-file during read, unit 1...
JuanPablo-Chile
If somebody has a few minutes I would appreciate it. I got the
following error when compyling my code:
Error--------------------------------------------------
forrtl: severe (24): end of file during read unit 1, file:C\.......
What I want to read is this: (file: apartado1.dat)__________________
(10: size of the matrix, the rest, the values of my matrix)
10
.7582 -.6919 .6802 -1.0725 .8998 -2.1231 .2847 -.
7333 -.7734 .1518
-.3368 .9708 -.1072 1.0135 -.4753 .0689 .3986
1.1163 .6205 -.2877
-1.3718 -.6859 .3317 -.9977 .2914 1.1071 .2450 .
1650 .4062 1.2160
1.4484 -1.0251 .2054 .5889 -.2640 2.4953 .8559 -.
8510 .8119 .7002
.7599 -1.7129 1.5370 -1.6098 1.1095 -1.1097 .3855 .
9652 .8183 .0370
-.9260 -.1119 -.8030 -1.6650 -.9014 .5883 .5542 -.
4152 .0618 .4574
.1990 .2576 2.0807 -2.2772 .3390 .2899 .6623 -.
5809 .8878 .1719
.8488 .9638 1.3219 -.0643 1.3171 .2280 -1.4296 -.
1497 -.5050 -1.7291
-.4175 -.6150 .7208 .3394 .8828 .2842 -.1455 -.
0896 .2892 1.1648
.8057 -1.3556 .1209 -.2222 .5717 -.3001 1.1343 -.
1794 -1.4671 1.3953
My code (if somebody hast the time to try it):
----------------------------------------------------------------------------------------------------------------------
implicit real*8 (a-h,o-z)
parameter (na_max= 100)
dimension a(na_max,na_max),v(na_max),w(na_max)
open (unit=1,file='apartado1.dat',status='old')
read (1,1020) ndim
write (6,*) ndim
do 69 i=1,ndim
read (1,1041) (a(i,j), j=1,ndim)
69 continue
write (6,*) a(1,1)
c----- writing the results
call write_result(ndim,a,v,w,x)
close(1)
stop
1020 format(2I8)
1041 format(1F8.4)
c stop
end
c-------------------------------------------------------
c----- Writing the results
subroutine write_result(n,a_mat,b,c,x)
implicit real*8 (a-h,o-z)
dimension a_mat(n,n),b(n),c(n)
open (unit=10,file='results.dat',status='old')
write (10,10)
do 20 i=1,n
write (10,30) (a_mat(i,j),j=1,n)
20 continue
close(10)
10 format ('The Matrix input is: '/)
30 format (5(1x,1pe14.6))
return
end
---------------------------------------------------------------------------------------
Last comments:
The thing is that I am leraning how to read files in fortran. After a
few headaches I have done this code. I can read the value 10, as you
can see after running the code. Now I want to read the values of the
matrix, I got many mistakes because of the format how to read the
numbers and save them in a file (results.dat). after a few
modifications the problem seems to solved but a new kind of error
appears, the end-of-file stuff.
Well, thanks to all for all this time reading this forum.
Thanks to the Fortran community
Gordon Sande
Hint 1: Write what was read immediately while debugging. Was it the
first or the last read that failed? You don't know from what was shown.
Hint 2: End-of-file is sometimes a problem with the last record being
incomplete due to a missing end-of-line because of text processing
problems. Add an extra blank line for a quick check. Read all the options
for you text editor to have it force an end-of-line at end (or get a
better text editor which will).
These hints are based on common problems of this sort as I did not read
your code becasuse you failed to say which version of which compiler on
which computer. But you get credit for showing the exact error and all
the code.
Richard Maine
> I got the following error when compyling my code:
> forrtl: severe (24): end of file during read unit 1, file:C\.......
I seriously doubt you got that error while compiling. That would be an
error from running it. But anyway...
> 10
> .7582 -.6919 .6802 -1.0725 .8998 -2.1231 .2847 -.
> 7333 -.7734 .1518
...
[mostly elided]
> do 69 i=1,ndim
> read (1,1041) (a(i,j), j=1,ndim)
> 69 continue
...
> 1041 format(1F8.4)
Note the "1" in the 1F8.4 in your format. This format defines 1 field on
a line - that's all. When your read statement tries to read 10 values,
this means that it reads 1 of them from the first line, since that's all
your format said to read from a line. Since there are still more values
to read, goes to the next line and reuses the format, reading 1 value
from that line. (This is called "format reversion" and in some cases
reuses only part of the format, but in your simple case, it reuses the
whole thing).
The important part is that when when the format is used up, the reading
then goes to the next line as part of reusing the format. It does not
multiply the effect of the format on the same line.
Thus the read statement for what you intend to be the first row ends up
reading 1 value from each of 10 lines instead of 10 values from 1 line.
When you try to tead the second row, you are at the end of the file.
Your format statement needs to be at least 10F8.4 to read 10 values from
a single line. It is harmless for the repeat factor (the 10) to be
larger than the number of values to be read, but if it it too small, you
will get the kind of behavior you are seeing. I recomend using a value
sufficiently large that it will always be large enough. For example, you
could use something like 999F8.4.
There are more sophisticated ways to handle such things, including ways
that don't require you to come up with a value guaranteed to be large
enough, but I would guess that this simple version is adequate for your
current purposes.
--
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain
Tobias Burnus
> For example, you
> could use something like 999F8.4.
>
> There are more sophisticated ways to handle such things, including ways
> that don't require you to come up with a value guaranteed to be large
> enough,
For instance in Fortran 2008; instead of 999F8.4 one can then write
*F8.4. Thus, if you have one of the very few compilers which already
implement it ...
Tobias
JuanPablo-Chile
I changed the code as you recommended and now I am geeting the next
error:
forrtl: severe (64): input conversion error, unit 1, fil C:\.....
--------------------------------------------------
the new line in the code:
...
1020 format(2I8)
1041 format(999F8.4)
...
-----------------------------------------------------
just in case I am using Visual Fortran 5.0 (Microsoft Developer Studio
97)
Jp
glen herrmannsfeldt
> I changed the code as you recommended and now I am geeting the next
> error:
> forrtl: severe (64): input conversion error, unit 1, fil C:\.....
Conversion error means that there are characters that it doesn't
expect to see, such as non-numeric characters in numbers.
It might also occur if you use tabs instead of spaces.
-- glen
Dick Hendrickson
machine, but it looks like the the 8th value on the second line, the
1.1163 starts in the wrong column. When you use a format like F8.4 then
every value must fit into an 8 column wide field and the fields must
start one after the other. The 1.1163 is shifted to the right by 2 spaces.
Dick Hendrickson
Richard Maine
> There's a line wrapping problem when I read your original post on my
> machine, but it looks like the the 8th value on the second line, the
> 1.1163 starts in the wrong column. When you use a format like F8.4 then
> every value must fit into an 8 column wide field and the fields must
> start one after the other. The 1.1163 is shifted to the right by 2 spaces.
I didn't check in detail because Dick is almost certainly right and he
got to it before I had a chance to look. But you might want to consider
using list-directed input instead of a fixed format. Fixed formats have
some advantages, but they are quite picky about things like this. If the
input data is generated by a program that guarantees to get it right,
then that's probably what you want. But insisting that humans type
things in getting the columns exactly right doesn't tend to work so
well.
List-directed input does also have some "issues". One significant one
that often confuses people is that it will read multiple lines if needed
to find enough fields for the read, which sometimes isn't what you
intend.
As one gets more sophisticated, there are other options that avoid some
of the "gotchas", but they are more complicated.
J. Clarke
Just for hohos I tried this in gfortran. Three problems
encountered--first, the "1f" vs "10f" that has already been mentioned,
second, the data provided is f9.4, not 8.4, third, the lines were
wrapped with a linefeed.
Changing the format statement to "1041 format(10F9.4)" fixed the first
two problems, and removing the linefeeds from the input file fixed the
third and it ran fine (aside from what appears to be a known bug in
gfortran regarding the use of "c" in the first column to denote a
comment). Also tried list directed and that worked fine with the
dataset provided.
steve
>
> Changing the format statement to "1041 format(10F9.4)" fixed the first
> two problems, and removing the linefeeds from the input file fixed the
> third and it ran fine (aside from what appears to be a known bug in
> gfortran regarding the use of "c" in the first column to denote a
> comment). Also tried list directed and that worked fine with the
> dataset provided.
A known bug in gfortran with a comment line? Can you
explain what you mean or point me to a bugzilla report?
--
steve
J. Clarke
I'm sorry, it's a "feature". C in the first column does not denote a
comment unless you're in fixed-form mode.
Richard Maine
> On 4/15/2010 9:23 PM, steve wrote:
> > On Apr 15, 5:43 pm, "J. Clarke"<jclarke.use...@cox.net> wrote:
> >>
> >> (aside from what appears to be a known bug in
> >> gfortran regarding the use of "c" in the first column to denote a
> >> comment).
> > A known bug in gfortran with a comment line? Can you
> > explain what you mean or point me to a bugzilla report?
>
> I'm sorry, it's a "feature". C in the first column does not denote a
> comment unless you're in fixed-form mode.
That has nothing to do with gfortran. That's part of the language spec.
If there is any compiler that doesn't act that way, that *WOULD* be a
bug in that it would fail to correctly compile perfectly valid Fortran
code - or even worse, would compile it and give incorrect results.
(Trivial to make examples of how that would happen). I doubt that any
compilers with that particular bug exist; it probably would have been
noticed and fixed long ago.
J. Clarke
> J. Clarke<jclarke...@cox.net> wrote:
>
>> On 4/15/2010 9:23 PM, steve wrote:
>>> On Apr 15, 5:43 pm, "J. Clarke"<jclarke.use...@cox.net> wrote:
>>>>
>>>> (aside from what appears to be a known bug in
>>>> gfortran regarding the use of "c" in the first column to denote a
>>>> comment).
>
>>> A known bug in gfortran with a comment line? Can you
>>> explain what you mean or point me to a bugzilla report?
>>
>> I'm sorry, it's a "feature". C in the first column does not denote a
>> comment unless you're in fixed-form mode.
>
> That has nothing to do with gfortran. That's part of the language spec.
> If there is any compiler that doesn't act that way, that *WOULD* be a
> bug in that it would fail to correctly compile perfectly valid Fortran
> code - or even worse, would compile it and give incorrect results.
> (Trivial to make examples of how that would happen). I doubt that any
> compilers with that particular bug exist; it probably would have been
> noticed and fixed long ago.
But code with comments containing in the first column _is_ perfectly
valid Fortran code.
Richard Maine
> But code with comments containing in the first column _is_ perfectly
> valid Fortran code.
No, it is not. Not in free source form, which is what you were talking
about. That is only valid in fixed source form. See he standard. It
isn't worth me dragging out the standard to cite the exact words, as it
is too trivial. Commentary conventions are part of source form.
There are no special columns in free source form; that's most of the
whole point. Specifically, column 1 is not special. The closest thing to
a column number dependence in free source form is that there is a limit
of 132 default characters of a free source form line.
If you have managed to find *ANY* compiler that gets this wrong, I would
be very intrigued. That ought to be a bit of a hint itself, although not
technically definitive. If one, or maybe a few, compilers refuse to
compile something, then a compiler bug is at least a possibility. Most
often it is an error in the code - often enough that it should be the
first assumption. But if every single compiler refuses to compile
something, that should be a pretty strong hint that maybe the code isn't
valid.
Note that the means of specifying whether code is free source form or
fixed source form is a separate matter. That part is not specified in
the standard. In particular, you might find a compiler that will accept
a file with a name ending in .f90 as fixed source form (I'm pretty sure
that gfortran will do so if you use an appropriate switch), but that's
not the matter at hand. I mention it only in case you might incorrectly
think you had found a counterexample just because you found a compiler
that would compile the code with a .f90 extension.
FX
And boy, does that suck.
--
FX
Richard Maine
> > there is a limit of 132 default characters of a free source form line.
>
> And boy, does that suck.
I suspect you are looking at it backwards then. That is common with
limits such as this. Look at it from the perspective of guarantee or
portability.
What this limit means is that, as long as you keep your code to no more
than 132 columns, you are guaranteed that no standard conforming
compiler will reject it for source code line length. I personally think
that is a nice kind of guarantee to have.
If that limit were not in the standard, then it would not mean that you
were guaranteed that you could use arbitrarily long source code lines.
What it would mean instead would be that different compilers could
choose different limits. Some compilers might well limit you to, say, 80
columns, or even the same 72 columns as fixed source form. Maybe some
oddball compiler would limit you to 64. You would have no guarantee of
anything. In my opinion, that would suck.
As it is now, different compilers can still have different limits. But
that requirement of the standard says that none of them can be less than
132 characters.
There are many limits like this in the standard where it can be
worthwhile to consider the perspective of portability guarantees. When
you do that, something that the standard describes as a maximum allowed
in a program can often be seen as a minimum that compilers are required
to support.
There can be, and often are, debates about exactly what those various
limits should be. They have tended to grow with time, as values that
once would have been prohibitively large for some systems are now safe
to assume for any system. But when people advocate removing the limits
entirely, I think they misunderstand what the effects of such removal
would be. For example, you might find that removing the limit of rank 7
for arrays, you code with rank 4 arrays is no longer sure to be accepted
on all compilers; that probably would not have been the intended effect.
A standard conforming compiler is perfectly free to allow source code
lines that are 4gb (or whatever) long and to support arrays with rank 42
(if you have enough memory, or maybe if enough of the dimensions have
extent 1). You just can't count on code that uses lines that long or
ranks that large to be portable.
J. Clarke
I stand corrected, and that then points to another bug in the sample
given. It uses "c" in the first line for comments but several lines
start in the first six columns, so it adheres neither convention.
steve
> On 4/16/2010 11:41 AM, Richard Maine wrote:
>
>
>
Please read the Fortran Standard. The code is fixed-form source
code. The only non-standard item I see on a quick glance is the
use of 'real*8' instead of 'double precision'. Indeed, ftnchek
shows that the code conforms to the Fortran 77 standard with
the exception of 'real*8', one variable name longer than 6 characters,
and two variables with an underscore in the name.
--
steve
Richard Maine
> ...that then points to another bug in the sample
> given. It uses "c" in the first line for comments but several lines
> start in the first six columns, so it adheres neither convention.
I was about to say that at a quick glance I didn't notice any such. In
fact, I didn't see them even at a second glance when counting more
carefully. But that appears to be because I must have been looking with
something that converted tabs to blanks. (Almost embarassed myself as a
result - wouldn't have been the first time). When I threw it at a
compiler to see if it noticed something I was missing... it did so. Yes,
the code appears to use a tab source form, which, as you correctly note,
is neither standard conforming fixed nor free source form. Now that I
think on it, I think someone mentioned that earlier as an aside
glen herrmannsfeldt
(snip)
> I was about to say that at a quick glance I didn't notice any such. In
> fact, I didn't see them even at a second glance when counting more
> carefully. But that appears to be because I must have been looking with
> something that converted tabs to blanks. (Almost embarassed myself as a
> result - wouldn't have been the first time). When I threw it at a
> compiler to see if it noticed something I was missing... it did so. Yes,
> the code appears to use a tab source form, which, as you correctly note,
> is neither standard conforming fixed nor free source form. Now that I
> think on it, I think someone mentioned that earlier as an aside
I mentioned tabs in the discussion on conversion error. I didn't count
the columns, but didn't see any non-numeric characters in the data.
I thought that the line breaks in the middle of numeric values were
part of the post process, and not part of the data. I then considered
that tabs in input data could be considered conversion errors.
-- glen
FX
> than 132 columns, you are guaranteed that no standard conforming
> compiler will reject it for source code line length. I personally think
> that is a nice kind of guarantee to have.
It would be much more useful if the standard required the compiler to
accept lines of any length. After all, the standard places no restriction
on the number of lines in the program, why should it have a restriction
for columns (other than historical reasons)?
I don't arguee for removing the limit, I argue for replacing the limit
with infinity.
--
FX
FX
> than 132 columns, you are guaranteed that no standard conforming
> compiler will reject it for source code line length. I personally think
> that is a nice kind of guarantee to have.
It would be much more useful if the standard required the compiler to
accept lines of any length. After all, the standard places no restriction
on the number of lines in the program, why should it have a restriction
for columns (other than historical reasons)?
I don't argue for removing the limit, I argue for replacing the limit
with infinity.
--
FX
glen herrmannsfeldt
When they start making computers with an infinite amount of
memory, then they might do that.
Note, for example, that some systems store records (lines) with
a length field in a finite number of bits.
The standard used to have a limit on the number of continuation
lines, which allows one to size a buffer big enough to hold all
the lines of one statement.
As Richard said, the limit is the minimum required. An implementation
might allow for infinity, but it isn't likely the standard will
be change to require that, as not all systems can support it.
(Actually, none can...)
-- glen
FX
>> accept lines of any length. After all, the standard places no restriction
>> on the number of lines in the program, why should it have a restriction
>> for columns (other than historical reasons)?
>
> memory, then they might do that.
Please address the unnatural dissimilarity between lines and numbers.
The standard, as far as I understand, does not place a limit on number of
lines (or total program length). By the same arguments you use, that
would be a deficiency of the standard.
--
FX
glen herrmannsfeldt
Not on total length, but systems may restrict it.
Fortran 2003 free form has a limit of 255 continuation lines, of,
as noted, up to 132 characters, limiting a single statement to
about 256*131 characters. (Allowing for & at the end of each line.)
That is a lot less than infinity, and allows one to plan buffer
sizes appropriately.
As Richard says, these numbers, as required by the standard, are
minimums for a standard implmentation. As extensions to the standard,
an implmentation may have larger limits.
On many, the total program length limit depends on the available
memory. It may be big or small depending on the size of a
specific system.
-- glen
Gordon Sande
Isn't it the case that an (very poor quality) implementation could reject
a two line program as being too complex although each line could be 132
characters long and still be conforming.
Realistically even a high quality implementaion might reject a 100,000,000 line
subroutine. Noone objects to compilers that can not generate 50GB of
object code.
It seems that you have missed the substance of Richards comments about how to
understand "standard speak" with its inverted uasge. Back when 640KB
more memory
than anyone might ever want there were conforming compilers that rejected
subroutines of several thousand lines as being too complex as the generated
object code was too large for the addressing mechanisms of the processor.
The standard tells the user the maximum that the user can use before
the compiler
might be allowed to complain about the complexity. Thus the users
maximum is the
compilers minimum. Just like Richard told you.
glen herrmannsfeldt
(snip)
> The standard, as far as I understand, does not place a limit on
> number of lines (or total program length). By the same arguments
> you use, that would be a deficiency of the standard.
I just noticed the requirement in fixed form that the END statement
not be continued. Presumably it is sometimes hard for the system
to recognize the END statement, though I have known systems in
the past that allowed it.
So, I tried it with gfortran. It seems that gfortran doesn't
allow the last statement to be a continued END, except
that it does allow it if it is followed by another statements,
such as SUBROUTINE.
-- glen
Richard Maine
> It would be much more useful if the standard required the compiler to
> accept lines of any length.
Then there would be no standard conforming compilers - ever. That is not
possible.
Note in this regard that the standard doesn't actually say "compiler".
For most purposes, we can ignore that, as it is a whole lot easier to
just say "compiler" than to use the standard's "processor" terminology
(with the necessary footnote about "processor" not meaning the same
thing as most people will naturaly read it to mean.)
But for the current question, the distinction is very relevant. The
standard's limitations are actually on the whole "processor", which
includes all the software and hardware necessary to make Fortran code
run. Thus, if the standard required support of infinite line size, the
vendor could not use the excuse that the finite limits are in the
operating system or hardware instead of in the compiler. If the system
taken as a whole did not allow infinite line size, then it would not be
standard conforming.
Yes, that is exactly how such a requirement would be interpreted in
standard-speak.
robert....@oracle.com
> J. Clarke <jclarke.use...@cox.net> wrote:
> > ...that then points to another bug in the sample
> > given. It uses "c" in the first line for comments but several lines
> > start in the first six columns, so it adheres neither convention.
>
> I was about to say that at a quick glance I didn't notice any such. In
> fact, I didn't see them even at a second glance when counting more
> carefully. But that appears to be because I must have been looking with
> something that converted tabs to blanks. (Almost embarassed myself as a
> result - wouldn't have been the first time). When I threw it at a
> compiler to see if it noticed something I was missing... it did so. Yes,
> the code appears to use a tab source form, which, as you correctly note,
> is neither standard conforming fixed nor free source form.
The presence of tabs in the representation of a program on
a storage medium does not preclude the program from being
standard conforming for a given implementation. Section 1.4
of the Fortran 2003 standard states
This standard does not specify
. . .
(3) The method of transcription of programs or
their input or output data to or from a
storage medium,
For example, a conforming processor could replace tabs in a
program with blanks while transcribing the program from a
storage medium. For such a processor, programs whose
representation on a storage medium contains tabs could be
a conforming program.
Bob Corbett
Richard Maine
> The presence of tabs in the representation of a program on
> a storage medium does not preclude the program from being
> standard conforming for a given implementation.
True in the abstract, for the reason that you state.
But the "for a given implementation" bit is central to the point. Using
tabs in the source code is detrimental to portability because such a
representation is not, in practice, portably interpreted among
implementations. In fact, although I agree that, in the abstract, a
processor could consider the tabs to be part of its "method of
transcription", I'm not aware of any processors that actually claim
that. There are processors that claim to support a tab source form as a
language extension, but that's different from claiming that it is part
of the method of transcription as referred to in that part of the
standard. If they did claim such support, they would need to do some
niggly bits appropriately; for example, character literals had better
get it appropriately "right". I bet the OP's processor doesn't do that.
In more specific support of my claim that such a transcription method is
detrimental to portability, when I tried to copy the source code in
question from the posting here, it failed to copy in such a way as to
correctly interpfret any such transcription method that might
theoretically have been intended. Instead, the compiler that I tried
reported it as being a nonstandard tab format. Therefore, if this code
was standard conforming for some particular implementation (which I
doubt), then it did not manage to copy appropriately for the
implementations that I have.
glen herrmannsfeldt
(snip)
> The presence of tabs in the representation of a program on
> a storage medium does not preclude the program from being
> standard conforming for a given implementation. Section 1.4
> of the Fortran 2003 standard states
> This standard does not specify
> . . .
> (3) The method of transcription of programs or
> their input or output data to or from a
> storage medium,
> For example, a conforming processor could replace tabs in a
> program with blanks while transcribing the program from a
> storage medium. For such a processor, programs whose
> representation on a storage medium contains tabs could be
> a conforming program.
At least back to Fortran-10 on the PDP-10/TOPS-10 systems.
The thing that I didn't like about that was that tabs were,
by system definition, every eight columns. A tab at the
beginning of a line went to column 8, but the compiler
counted it as column 7. It would print out in listings
at column 8. Well, the other way to look at it is that lines
go until column 73 if they start with a tab. That part I
didn't like. I didn't use tabs in my Fortran programs.
If instead it counted as column 8 (so one fewer available
for the Fortran statement) then listings would be consistent,
and programs that convert to/from tabs would result in
compilable results either way.
-- glen
J. Clarke
And what do you believe it will tell me?
> The code is fixed-form source
> code.
So it's OK for fixed-form source code to have the word "end" starting in
column 5?
> The only non-standard item I see on a quick glance is the
> use of 'real*8' instead of 'double precision'.
Compile it and get back to us. I didn't take a quick glance, I compiled
and ran it.
> Indeed, ftnchek
> shows that the code conforms to the Fortran 77 standard with
> the exception of 'real*8', one variable name longer than 6 characters,
> and two variables with an underscore in the name.
So it _is_ OK for the word "end" to appear in Column 5?
>
> --
> steve
robert....@oracle.com
Transferring files between file systems that use incompatible
file formats is always going to be an issue. I have used
FORTRAN compilers where every line of a source program had
to be the same length because the file system stored text as
fixed-length records. Some people now think that
transferring source files between Windows, Macs, UNIX,
and UNIX-like operating systems is a bother because of the
different line terminators. They have no idea how much
trouble transferring source files used to be. Of course,
the fact that each machine had its own character set(s)
made such transfers all the more interesting.
One advantage of using fixed-length records was that it was
possible to consider any character that was representable on
the machine as a member of the FORTRAN processor's
processor character set. That was not possible for systems
that used control characters to designate the end of a line.
The FORTRAN 77 standard required a FORTRAN processor to allow
any character in the processor's processor character set to
appear in a character context. Whatever characters were used
as line terminators were excluded from the processor
character set. Typically, a few other characters were also
excluded from the processor character set, tabs and form
feeds frequently among them.
Bob Corbett
Richard Maine
> On Apr 16, 7:39 pm, nos...@see.signature (Richard Maine) wrote:
> > In more specific support of my claim that such a transcription method is
> > detrimental to portability, when I tried to copy the source code in
> > question from the posting here, it failed to copy in such a way as to
> > correctly interpfret any such transcription method that might
> > theoretically have been intended. Instead, the compiler that I tried
> > reported it as being a nonstandard tab format. Therefore, if this code
> > was standard conforming for some particular implementation (which I
> > doubt), then it did not manage to copy appropriately for the
> > implementations that I have.
>
> Transferring files between file systems that use incompatible
> file formats is always going to be an issue.
...[elided]
Yes, that is all very fine in theory. In practice, though...
1. This one did not "transfer correctly" for me.
2. All this theorizing ignores the fact that the processor in question
does not, in fact, claim to use such a transcription method - at least
not to my knowledge. I do not deny that such a processor could exist in
theory. I know of no examples in practice that claim to support the
transcription method in question, whereby tabs in the source file are
claimed to be standard conforming for that processor. If you know of
any, I'd be interested in hearing of them. I would be even more
interested if you happened to have information that shows that the OP's
processor made such a claim.
3. Short of any such processors being found, I maintain the substance of
the claim that started this subthread, namely "the code appears to use a
tab source form, which, as you correctly note, is neither standard
conforming fixed nor free source form." In particular:
I still maintain that the code "appears" to use a tab source form. I
grant the abstract possibility that the appearance might be incorrect,
but I still claim that is the appearance.
I also claim that tab source form is nonstandard. I grant that a
processor could use a file representation that involved tabs, but then
that would not be a source form. It would be a transcription method.
I finally still maintain that the code presented is nonstandard for all
processors I have heard of, and for the OP's processor in particular. I
grant the abstract possibility that someone could make a processor for
which the file in question was standard conforming. I also suppose that
is probably slightly more interesting than consideration of the number
of angels that could dance on the head of a pin, but only slightly. I
doubt either will be of much help to the OP in writing portable,
standard conforming Fortran for compilers (or "processors") that exist.
glen herrmannsfeldt
(snip)
> Transferring files between file systems that use incompatible
> file formats is always going to be an issue. I have used
> FORTRAN compilers where every line of a source program had
> to be the same length because the file system stored text as
> fixed-length records.
I did much Fortran programming on such systems.
> Some people now think that
> transferring source files between Windows, Macs, UNIX,
> and UNIX-like operating systems is a bother because of the
> different line terminators. They have no idea how much
> trouble transferring source files used to be. Of course,
> the fact that each machine had its own character set(s)
> made such transfers all the more interesting.
Such as ASCII/EBCDIC translation... One that still comes
up sometimes is that ASCII doesn't have a not sign, and
EBCDIC doesn't have tilde. Some translation tables translate
between those, though there are some other possibilities.
> One advantage of using fixed-length records was that it was
> possible to consider any character that was representable on
> the machine as a member of the FORTRAN processor's
> processor character set.
I do remember using one of those systems from Fortran,
with a NEWLINE character in a character constant.
(Well, as close as you could come to that in Fortran 66.)
EBCDIC has a newline character in addition to CR and LF,
and it could be used for terminal I/O on some systems.
> That was not possible for systems
> that used control characters to designate the end of a line.
> The FORTRAN 77 standard required a FORTRAN processor to allow
> any character in the processor's processor character set to
> appear in a character context. Whatever characters were used
> as line terminators were excluded from the processor
> character set. Typically, a few other characters were also
> excluded from the processor character set, tabs and form
> feeds frequently among them.
I have at times written programs to do bit image graphics
on various printers, which often requires the ability to send
all 256 possible bit combinations in a byte.
But fixed length records have the problem that you don't know
where the record end is. Not quite as bad as losing some bit
combinations, but still it can cause problems.
-- glen
robin
news:b7a79b86-b8fd-4f5b...@c36g2000yqm.googlegroups.com...
| Hi:
|
| I changed the code as you recommended and now I am geeting the next
| error:
|
| forrtl: severe (64): input conversion error, unit 1, fil C:\.....
As has already been suggested, you need to print the values
after each read statement, so that you can see where the program
got up to.
That way, you can deduce which line of data is a fault,
and can rectify it.