Detect EOF for direct access, unformatted files?

[Leif Harcke]

Suppose you have a number of binary, fixed length records in a file.
The number of such records is unknown at run time, but the record size
is known or provided. How do you prevent yourself from running off
the end of the file?

Is there a way to detect "end of file" for direct access, unformatted
files? The Fortran standard requires IOSTAT < 0 be returned only for
sequential files that read an EOF record. For direct access files, no
such requirement to return IOSTAT < 0 exists.

After investigating the behavior of a number of f77 and f90 compilers
on different UNICES, it appears some run-time systems generate an
ERROR, while some set IOSTAT=-1 upon reading past the last record in a
direct access, unformatted file.

Looks like the best portable way to avoid running off the end is to
get the file size via a call to the IOSTAT intrinsic and then divide
by the known record size to get the maximum possible record number.
Then, make sure you never exceed this number on a READ statement. Of
course, IOSTAT isn't standard, but most UNIX-based compilers seem to
provide it. Any other suggestions?

-Leif

[r***@sun.com]

Post by Leif Harcke
Is there a way to detect "end of file" for direct access, unformatted
files? The Fortran standard requires IOSTAT < 0 be returned only for
sequential files that read an EOF record.

The Fortran standard does not provide a way to detect end-of-file
for a direct-access file. The standard does not apply the concept
end-of-file to direct-access files. The Fortran standard does not
allow a standard conforming program to try to read a record that
does not exist. If a program does try to read a record that does
not exist, the standard no longer has anything to say about the
behavior of the program, and so, a conforming implementation is
free to report an end-of-file condition (or do anything else).

Bob Corbett

[Richard E Maine]

Post by Leif Harcke
Is there a way to detect "end of file" for direct access, unformatted
files?

Bob Corbett summarized the situation. Fundamentally, the concept of
end-of-file doesn't make sense for a direct access file. It doesn't have
a beginning, some records, followed by an end. It just has some records
with record numbers. Although pretty much all current implementations
happen to implement the concept in a way that might lead you to think of
an end-of-file concept, that is an artifact of the particular (very
common) implementation - it isn't really part of the definition. It is
possible to have implementations where the records aren't stored in
numerical order at all, but instead are accessed by something like a
hash table.

The most appropriate concept is not end-of-file, but an error. Many
implementations will return an error (i.e. iostat>0). However, the
standard doesn't require this. Some implementations might not detect the
error at all, but just return some random data (maybe 0's,m maybe not).
The standard allows this. In fact, that's the behavior I'd expect as
most likely if there was a record "missing" in the middle of the file
and you tried to read it. Most implementations would probably have just
filled that part of the file with zero and won't "know" that it is
supposed to be missing. From the standard's perspective, there is no
difference between a record missing in the "middle" of the file and one
missing off the "end"; they are all just missing records.

Some implementations do seem to return and end-of-file. I regard that as
bizarre and inappropriate, but there have been implementations that do
it. Since a program that reads a nonexistent record is nonstandard, the
implementation is allowed to do pretty much anything. The program is
erroneous, but it is not an error that the implementation is required to
detect.

You might have reasonably good odds if you test for nonzero iostat, but
the standard guarantees nothing about it.

As you mentioned, finding the file size works, but that isn't standard
(or even particularly widespread) until f2003. F2003 does have a file
size inquiry option in inquire, though that won't help you much yet.

In short, you are seeing just one of the many reasons why the f2003
stream files will be so appreciated. You can usually get things done
today without them, but portability is a big problem.

[Leif Harcke]

Post by Leif Harcke
Looks like the best portable way to avoid running off the end is to
get the file size via a call to the IOSTAT intrinsic

This, of course, should read FSTAT (the UNIX system call), not IOSTAT.

Post by Leif Harcke
and then divide
by the known record size to get the maximum possible record number.
Then, make sure you never exceed this number on a READ statement. Of
course, IOSTAT isn't standard, but most UNIX-based compilers seem to

Again, insert "FSTAT isn't standard Fortran" here...

Post by Leif Harcke
provide it. Any other suggestions?

Thanks to Robert and Richard for responding. Looks like porting this
code will be lots of fun, since the programmer relied upon the
run-time system generating an ERROR when reading past the end of a
direct access, unformatted file, and all Fortrans don't necessarily
exhibit this behavior. Fortunately, the behavior of FSTAT is covered
by the UNIX standards.

-Leif

[Greg Lindahl]

Fortunately, the behavior of FSTAT is covered by the UNIX standards.

Yes, but the relationship between the size given by fstat() and
Fortran record lengths and direct access files isn't covered by any
standard. It's likely to work and be portable to most all Unixes,
but you have less guarantee than you think you have.

-- greg

[Clive Page]

Post by Leif Harcke
Thanks to Robert and Richard for responding. Looks like porting this
code will be lots of fun, since the programmer relied upon the
run-time system generating an ERROR when reading past the end of a
direct access, unformatted file, and all Fortrans don't necessarily
exhibit this behavior. Fortunately, the behavior of FSTAT is covered
by the UNIX standards.

Although Richard Maine has responded in his usual helpful style with the
official position, which is that with a direct-access file there is no
real concept of an "end", and that when you read a direct-access record
which does not exist the Fortran system is free do anything it wants,
from ignoring the condition to reporting an error (I'm surprised he
didn't mention starting World War III, but maybe that's no longer
politically correct :-).

But I have to say that being able to detect the "end" of a direct-access
file is something that many of us have needed to do for many years. My
own code simply tries to read each record with an IOSTAT= item in the
READ statement, and testing the variable for non-zero. As others have
reported, some systems return -1 meaning end-of-file, but the majority
of systems return a positive non-zero error code. I have used code
exercising this feature on at least a dozen compilers on almost as many
platforms over many years, and have *never* encountered a system which
returns zero for a record beyond the "end" of the direct-access file.
My own opinion is therefore that testing the IOSTAT return code for zero
versus non-zero is pretty highly portable. It is a pity that this
behaviour is not Standard, but I wish to claim that it is a de-facto
standard.

But of course I could be wrong as I have not tested it on anything like
every combination of compiler and operating system on the market - and
would be interested to know if anyone has encountered a system in which
that is not a safe way of detecting the "end" of the direct-access file.

[Richard E Maine]

Post by Clive Page
would be interested to know if anyone has encountered a system in which
[IOSTAT] is not a safe way of detecting the "end" of the direct-access
file.

I think so, but I'm not entirely sure. I try to avoid assuming it, so I
don't go to a lot of trouble to test it. There are times when I break
down and do it because there isn't much of a better way today (I've
worked on plenty of systems that don't have fstat - and even on those
that do, calling it from Fortran has varied), but when I do so, I've
acknowledged the potential portability problem and just check it on the
systems that I know I particularly need.

I think I recall some cases from long ago, but memory is too vague for
me to be sure. I'm thinking of cases where the system didn't actually
have a way of recording file size down to the exact byte, but just to
the next allocation unit, whatever that was. In that case, you are
likely to get bogus data if you read a record past what you would
consider the "end", but still within the last block.

I might go out on a limb and suggest possibly Apple Fortran on UCSD
Pascal. That certainly had some I/O "funniness" (including failure to
implement backspace for unformatted sequential - I recall that mostly
because of the lame "excuse", which they would have done better not to
mention IMO).

And, of course, any Fortran 66 compiler, but that's "cheating". For
those who might not know, F66 had no iostat, end=, err=, or any way to
detect end of file in any circumstances. It was common to do hacks like
putting 999 or some other flag value as the last record of a file to
work around the lack.

[Gordon Sande]

Post by Richard E Maine
I might go out on a limb and suggest possibly Apple Fortran on UCSD
Pascal. That certainly had some I/O "funniness" (including failure to
implement backspace for unformatted sequential - I recall that mostly
because of the lame "excuse", which they would have done better not to
mention IMO).

That was a PCode system for Apple ][ that came on multiple 140k
floppies and ran in the 48k that was for users. Or at least that
was the version that I had.

Did their excuses include lack of an equivalent notion in Pascal?

[Richard E Maine]

Post by Gordon Sande

Post by Richard E Maine
I might go out on a limb and suggest possibly Apple Fortran on UCSD
Pascal. That certainly had some I/O "funniness" (including failure to
implement backspace for unformatted sequential - I recall that mostly
because of the lame "excuse", which they would have done better not to
mention IMO).

Did their excuses include lack of an equivalent notion in Pascal?

Nah. They claimed that the standard was in error for specifying
backspace for unformatted files because it was impossible to implement
(on any system). Apparently the idea of storing a record length at the
end of the record as well as the beginning didn't occur to them (and
therefore it was impossible). I recall that it seemed to me like a
pretty poor attempt to blame their difficulty on someone else; it would
have gone over much better with me anyway if they had just said that
they couldn't implement it or it was too difficult in their system or
some such, rather than trying to say it was an error in the standard.

I do now recall one other "interesting" point about their direct access
implementation - this one a plus. I amused myself in the early 80's by
including a tiny program in my evaluation benchmarks. That program ran
fine in almost zero time with Apple Fortran. It brought every other
system I tried it on to its figurative knees. All the program did was
write a very small number (might even have been only 1) of small records
to a direct access file, read the record back, and print some data from
it to verify correct functioning. You are probably wondering what the
catch is. The record number was something ludicrously large. On the
Apple, it made a tiny "holey" file (i.e. the huge part of the file that
had never been written was not physically stored on disk). All the
"mainframe" systems I tried it on pretty much died as they filled up all
the disk space they had trying to write hundreds of megabytes (which was
huge in that day) of zeros to disk.

So my Apple beat the heck out of every other system I tried that small
benchmark on - by many orders of magnitude. But we didn't buy an Apple
for our central computer anyway. :-) That was when we bought our Elxsi
(and coincidentally when I met Bob Corbett, who has also posted to this
thread).

By the way, I do agree with Clive that, as long as you test for non-zero
instead of specifically for <0 or >0, iostat does work on at least many
systems. So it isn't an unreasonable thing to try. I'd just make sure to
document it as a potential system dependence. I've got several things in
my "system dependent I/O" module that I label as system dependent even
though I've never actually had to change the code; I just acknowledge
the potential.

[Leif Harcke]

I have used code exercising this feature on at least a dozen
compilers on almost as many platforms over many years, and have
*never* encountered a system which returns zero for a record beyond
the "end" of the direct-access file.

$ gfc -v
Using built-in specs.
Target: i386-linux
Configured with: ../gcc/configure --prefix=/tmp/gfortran-20050423/irun --enable-languages=c,f95 --host=i386-linux
Thread model: posix
gcc version 4.1.0 20050423 (experimental)

$ gfc filesize.f

$ ./a.out

i: 1 myiostat: 0
i: 2 myiostat: 0
i: 3 myiostat: 0
i: 4 myiostat: 0
i: 5 myiostat: 0
i: 6 myiostat: 0
i: 7 myiostat: 0
i: 8 myiostat: 0
i: 9 myiostat: 0
i: 10 myiostat: 0
i: 11 myiostat: 0
Bus error (core dumped)


$ cat filesize.f
implicit none

integer i,j
integer myarray(100)
integer myiostat

do i=1,100
myarray(i) = i
end do

open(unit=10,file='filesize.out', access='direct',
& status='replace', recl=400)
do i=1,10
write(unit=10,rec=i) (myarray(j), j=1,100)
end do
close(unit=10)

open(unit=20, file='filesize.out', access='direct',
& status='old', recl=400)
do i=1,20
read(unit=20, rec=i,err=100, iostat=myiostat)
& (myarray(j), j=1,100)
print *, 'i: ', i, ' myiostat: ', myiostat
end do
close(unit=20)

! spaghetti jump to end if no error
go to 300

! else handle error here
100 print *, 'error encountered'
print *, 'i: ', i, ' myiostat: ', myiostat

300 continue
end

[Walter Spector]

Post by Clive Page
...
But I have to say that being able to detect the "end" of a direct-access
file is something that many of us have needed to do for many years...

Or at least to know whether the record exists or not.

Consider the following snippet:

open (42, file=..., access='direct', status='new', recl=...)
write (42, rec=1) record1
write (42, rec=10) record10
read (42, rec=5, iostat=ioerr) record5
print *, 'i/o error =', ioerr
...

What should happen here?

I have worked on systems which exhibited the following:

a.) The WRITE to record10 was illegal because records 2-9 have not
been written yet. Thus one never gets to the READ.

b.) The WRITE to record10 completes, but 'under the table' the I/O
system fills the intermediate records with zeros (or worse yet, garbage.)
So the READ completes, but who knows what to expect...

Most modern systems fall into the latter category.

There are no doubt other possibilities. For example, one might like
to efficiently (spacewise) support 'sparse' record arrangements.
So plausible implementations of direct access could even include
ISAM or RDB type support. The Standard is written to allow this
possiblity.

Post by Clive Page
....
My own opinion is therefore that testing the IOSTAT return code for zero
versus non-zero is pretty highly portable. It is a pity that this
behaviour is not Standard, but I wish to claim that it is a de-facto
standard.

But even if it were so, depending on it would lead to non-portable code.

Granting that pretty much all modern systems store the records consecutively
in flat files, there is still the problem of alignment of records. Some
align each record on numeric storage unit boundaries, some on character
storage unit boundaries. (I can point to current examples of both.)
And some systems even round the file size up to some convenient multiple
of disk sector size and/or I/O buffer size. Because of this, the I/O
library on one system might indicate EOF very differently than another.

Walt
-...-
Walt Spector
(w6ws at earthlink dot net)

[Richard E Maine]

Post by Walter Spector
open (42, file=..., access='direct', status='new', recl=...)
write (42, rec=1) record1
write (42, rec=10) record10
read (42, rec=5, iostat=ioerr) record5
print *, 'i/o error =', ioerr
...
a.) The WRITE to record10 was illegal because records 2-9 have not
been written yet. Thus one never gets to the READ.

That compiler behavior pretty explicitly violates the standard. Of
course, I could believe that you saw it anyway. But about the only way a
vendor could justify that as standard conforming compiler behavior would
be to appeal to the "cop out" clause - the one that says a compiler
doesn't have to be able to do things that aren't supported by the
device. That clause, taken to the extreme, allows a compiler to say that
no I/O at all is supported. Its more realistic application would include
things like writing to devices that can only do input, etc.

[Gary L. Scott]

Post by Richard E Maine

Post by Walter Spector
open (42, file=..., access='direct', status='new', recl=...)
write (42, rec=1) record1
write (42, rec=10) record10
read (42, rec=5, iostat=ioerr) record5
print *, 'i/o error =', ioerr
...
a.) The WRITE to record10 was illegal because records 2-9 have not
been written yet. Thus one never gets to the READ.

I think the ones I've used simply write records 2-9 "behind the scenes"
and include some sort of "not yet written") marker "in" the record. So
you still can't read from them (until you write them), but it keeps the
file structure consistent with a fixed length sequential file.
Likewise, they offer a "delete" function which simply marks them as "not
written" (or something). Does that make sense?

Post by Richard E Maine
That compiler behavior pretty explicitly violates the standard. Of
course, I could believe that you saw it anyway. But about the only way a
vendor could justify that as standard conforming compiler behavior would
be to appeal to the "cop out" clause - the one that says a compiler
doesn't have to be able to do things that aren't supported by the
device. That clause, taken to the extreme, allows a compiler to say that
no I/O at all is supported. Its more realistic application would include
things like writing to devices that can only do input, etc.

--
Gary Scott
mailto:***@ev1.net

Fortran Library: http://www.fortranlib.com

Support the Original G95 Project: http://www.g95.org
-OR-
Support the GNU GFortran Project: http://gcc.gnu.org/fortran/index.html

Why are there two? God only knows.


If you want to do the impossible, don't hire an expert because he knows
it can't be done.

-- Henry Ford

[Walter Spector]

...
That compiler behavior pretty explicitly violates the standard...

It was quite a while ago in the Fortran-77 days. Said vendor did
change/fix their library. (Thankfully.) IIRC, their concern was
uninitialized data in the file being a security risk or somesuch.

Walt
-...-
Walt Spector
(w6ws at earthlink dot net)

[glen herrmannsfeldt]

Richard E Maine wrote:
(snip regarding direct access files)

Post by Richard E Maine

Post by Walter Spector
a.) The WRITE to record10 was illegal because records 2-9 have not
been written yet. Thus one never gets to the READ.

That compiler behavior pretty explicitly violates the standard. Of
course, I could believe that you saw it anyway. But about the only way a
vendor could justify that as standard conforming compiler behavior would
be to appeal to the "cop out" clause - the one that says a compiler
doesn't have to be able to do things that aren't supported by the
device. That clause, taken to the extreme, allows a compiler to say that
no I/O at all is supported. Its more realistic application would include
things like writing to devices that can only do input, etc.

I agree. The OS/360 compilers would detect that the file didn't
exist on the first open and write all the records. There is a special
process for doing it, which is pretty much writing a sequential file
with the appropriate record length.

To do that, though, it is necessary to know the total number
of records at first OPEN. The S/360 DEFINE FILE statement includes
this, but I don't see it in the standard OPEN statement.

-- glen

[David Frank]

FWIW,
CVF reports a error condition if the file is read accessed beyond where a
EOF mark is written.
but reports "ok" if the the endfile statement is removed.

! -----------------
program test
integer :: n
character(20) :: string = 'the quick brown fox'

open (1,file='test.dat',access='direct',form='binary',recl=100)
do n = 1,100
write (1,rec=n) n,string
end do
endfile (1)

read (1,rec=200,err=101) n,string
write (*,*) n,string
stop 'ok'
101 write (*,*) 'error'
end program

[Clive Page]

Post by David Frank
FWIW,
CVF reports a error condition if the file is read accessed beyond where a
EOF mark is written.
but reports "ok" if the the endfile statement is removed.
! -----------------
program test
integer :: n
character(20) :: string = 'the quick brown fox'
open (1,file='test.dat',access='direct',form='binary',recl=100)
do n = 1,100
write (1,rec=n) n,string
end do
endfile (1)
read (1,rec=200,err=101) n,string
write (*,*) n,string
stop 'ok'
101 write (*,*) 'error'
end program

I didn't think that ENDFILE was permitted on a unit opened for direct
access?

[Richard E Maine]

Post by Clive Page
I didn't think that ENDFILE was permitted on a unit opened for direct
access?

It isn't - for the same reason that end-of-file isn't defined.
I wouldn't count on other vendors accepting it.

[Clive Page]

I finally got around to writing a very simple test program and running
it on all the compilers I could access easily:

program testda
! shows the IOSTAT code when reading beyond end of direct-access file
integer irec, ival, status
open(unit=1,file='t.tst',status='NEW',access='DIRECT',recl=4)
write(1, rec=1) 12345678
close(unit=1)
open(unit=2,file='t.tst',status='OLD',access='DIRECT',recl=4)
do 15, irec = 1,2
read(2, rec=irec, iostat=status) ival
print *,'record ', irec, ' status=', status
15 continue
close(unit=2, status='DELETE')
end

Results so far:

Linux g77 -1
Linux NAG f95 v4.1 214
Linux g95 25/1/2005 214
Linux Intel ifort v8.1 36
Linux Portland pgf95 v6.0.2 253
Linux Pathscale pathf90 v2.1 4016
Irix MIPSpro f77 168
Irix MIPSpro 7 f95 4016
Solaris SUN Fortran95 v7.1 f77 -1
Solaris SUN Fortran95 v7.1 f95 1066

It is notable that the only compilers to return -1 (end-of-file) are
those implementing Fortran77.

The great variety of error numbers for the same condition is notable. Of
course Fortran2003 will provide a way to translate these numbers to
something more meaningful. In the mean time, it occurs to me that it
would be nice to have some code which exercised all the more common I/O
error conditions and reported on the resulting IOSTAT return values,
since it is surprisingly hard to find a list of error numbers in the
documentation of many vendors. Maybe someone has already written
something to do this, but I'm not aware of any.

[Richard E Maine]

Post by Clive Page
In the mean time, it occurs to me that it
would be nice to have some code which exercised all the more common I/O
error conditions and reported on the resulting IOSTAT return values,
since it is surprisingly hard to find a list of error numbers in the
documentation of many vendors. Maybe someone has already written
something to do this, but I'm not aware of any.

I agree it would be nice. Alas, I think you will find it difficult to do
because there is likely to be a difference deeper than just the numbers.
Some vendors will have several different numbers for what you might
think of as the same error, depending on details that you might think
irrelevant.

I ran into this in getting the IOSTAT_END and IOSTAT_EOR named constants
in f2003 (at east those 2 cases are there). I had initially thought this
was a pretty "non-invasive" specification - allowing the vendors to
continue using whatever iostat values they wanted, but just making them
say what it was. Turned out, though, that some vendors have multiple
iostat values for eof, depending on such things as whether it is an
internal or external file, formatted vs unformatted, etc.

I claim that such an implementation actually violates the standard and
that the user is allowed to write code that depends on iostat for eof
always being the same (for instance, by generating a known eof error and
then testng for that iostat value from later reads).

The only counter-argument I've seen was that my claim was based on
reading the standard carefully and, for example, understanding the
difference between "the" and "a". An argument explicitly based on sloppy
reading doesn't seem like much of a counter to me. It isn't like my
reading was particularly subtle or complicated - more a matter that
apparently some people just hadn't read the actual words that were there.

There was an attempt, when this was pointed out, to revise the standard
to make such implementations valid. I pointed out that this would
actually make existing standard-conforming codes nonstandard. That
argument eventually won out.

Anyway, for errors (as opposed to eof and eor), you could run into
similar complications, and the standard doesn't help there. I've had
enough problems with some compilers not considering "common errors" to
be errors at all, much less having consistent iostat values (unless you
consider zero to be a consistent value :-().

[Clive Page]

Post by Richard E Maine
I agree it would be nice. Alas, I think you will find it difficult to do
because there is likely to be a difference deeper than just the numbers.
Some vendors will have several different numbers for what you might
think of as the same error, depending on details that you might think
irrelevant.

I'm sure you are right that it will be difficult. Another complication,
it occurs to me, is that some conditions might crash a program using
some compiler which with other compilers merely gave rise to the return
of non-zero status. I'm not sure to what extent the Standard allows
such behaviour, but I have a dim memory of having been bitten by it in
the past.

[Dan Nagle]

Hello,

I'm very short of time just now or I'd do it myself.
But I'd be interested in seeing this run on a variety of compilers
modified to write, say, 1 and 3, and see whether the error codes
for reading 2 and 4 were the same.

Also, CLive Page has access to more compilers than I do. :-)

Post by Clive Page
I finally got around to writing a very simple test program and running
program testda
! shows the IOSTAT code when reading beyond end of direct-access file
integer irec, ival, status
open(unit=1,file='t.tst',status='NEW',access='DIRECT',recl=4)
write(1, rec=1) 12345678
close(unit=1)
open(unit=2,file='t.tst',status='OLD',access='DIRECT',recl=4)
do 15, irec = 1,2
read(2, rec=irec, iostat=status) ival
print *,'record ', irec, ' status=', status
15 continue
close(unit=2, status='DELETE')
end
Linux g77 -1
Linux NAG f95 v4.1 214
Linux g95 25/1/2005 214
Linux Intel ifort v8.1 36
Linux Portland pgf95 v6.0.2 253
Linux Pathscale pathf90 v2.1 4016
Irix MIPSpro f77 168
Irix MIPSpro 7 f95 4016
Solaris SUN Fortran95 v7.1 f77 -1
Solaris SUN Fortran95 v7.1 f95 1066
It is notable that the only compilers to return -1 (end-of-file) are
those implementing Fortran77.

I may add this check to make_processor_model
after the end-of-term crunch I'm in just now.

[John Harper]

Post by Dan Nagle
But I'd be interested in seeing this run on a variety of compilers

Post by Clive Page
program testda
! shows the IOSTAT code when reading beyond end of direct-access file
integer irec, ival, status
open(unit=1,file='t.tst',status='NEW',access='DIRECT',recl=4)
write(1, rec=1) 12345678
close(unit=1)
open(unit=2,file='t.tst',status='OLD',access='DIRECT',recl=4)
do 15, irec = 1,2
read(2, rec=irec, iostat=status) ival
print *,'record ', irec, ' status=', status
15 continue
close(unit=2, status='DELETE')
end

Run-time output from that program with Compaq, either f77 or f95 (i.e.
Compaq Fortran 77 V5.5-14 or Compaq Fortran V5.5-1877), are the same:
record 1 status= 0
record 2 status= 36

John Harper, School of Mathematics, Statistics and Computer Science,
Victoria University, PO Box 600, Wellington, New Zealand
e-mail ***@vuw.ac.nz phone [phone] fax [phone]

[Phillip Helbig---remove CLOTHES to reply]

Post by John Harper
Run-time output from that program with Compaq, either f77 or f95 (i.e.
record 1 status= 0
record 2 status= 36

This is from Fortran on VMS (pretty much the latest versions of compiler
and OS):

record 1 status= 0
record 2 status= 36

Of course, Compaq Fortran and the current HP Fortran are derived from
DEC Fortran, so no surprise that the results are the same.

[Clive Page]

Post by Dan Nagle
I'm very short of time just now or I'd do it myself.
But I'd be interested in seeing this run on a variety of compilers
modified to write, say, 1 and 3, and see whether the error codes
for reading 2 and 4 were the same.
Also, CLive Page has access to more compilers than I do. :-)

That's an interesting idea. I'll do that as soon as I get a few minutes
spare.

[b***@aol.com]

Post by Clive Page
I finally got around to writing a very simple test program and

running
<code snipped>

Post by Clive Page
Linux g77 -1
Linux NAG f95 v4.1 214
Linux g95 25/1/2005 214
Linux Intel ifort v8.1 36
Linux Portland pgf95 v6.0.2 253
Linux Pathscale pathf90 v2.1 4016
Irix MIPSpro f77 168
Irix MIPSpro 7 f95 4016
Solaris SUN Fortran95 v7.1 f77 -1
Solaris SUN Fortran95 v7.1 f95 1066

Here are the results on Windows XP. There may be a problem with
gfortran.

Intel 8.0 36
Lahey 7.1 80
Absoft 8.2 -1
g77 2.95.2 213
g95 4/5/2005 213
gfortran 2/8/2005 0

[Ian Chivers]

here are some additional results.

Nag

record 1 status= 0
record 2 status= 214

Salford ftn95

record 1 status= 0
record 2 status= 95

Intel

record 1 status= 0
record 2 status= 36

CVF

record 1 status= 0
record 2 status= 36

Lahey

record 1 status= 0
record 2 status= 36

Post by Leif Harcke

Post by Clive Page
I finally got around to writing a very simple test program and

running
<code snipped>

Post by Clive Page
Linux g77 -1
Linux NAG f95 v4.1 214
Linux g95 25/1/2005 214
Linux Intel ifort v8.1 36
Linux Portland pgf95 v6.0.2 253
Linux Pathscale pathf90 v2.1 4016
Irix MIPSpro f77 168
Irix MIPSpro 7 f95 4016
Solaris SUN Fortran95 v7.1 f77 -1
Solaris SUN Fortran95 v7.1 f95 1066

Here are the results on Windows XP. There may be a problem with
gfortran.
Intel 8.0 36
Lahey 7.1 80
Absoft 8.2 -1
g77 2.95.2 213
g95 4/5/2005 213
gfortran 2/8/2005 0

[Clive Page]

Post by b***@aol.com

Post by Clive Page
Linux g95 25/1/2005 214

Here are the results on Windows XP. There may be a problem with
gfortran.
g95 4/5/2005 213

It's odd that g95 appears to give different error codes on WinXp and on
Linux. I just ran the program on g95 on my laptop (WinXP) and I got 214
also on that platform. Could it have been a data entry error on you
part?