recl on g95 and gfortran

recl on g95 and gfortran

Post by beliavsk » Thu, 29 Jun 2006 04:45:06


For the following program compiled and run on Windows XP

program xrecl
implicit none
integer , parameter :: in_unit=20,out_unit=21
character (len=*), parameter :: in_file="xrecl.dat"
integer :: jrecl
open (unit=out_unit,file=in_file,action="write",status="replace")
write (out_unit,*) "24"
close (out_unit)
do jrecl = 4,1,-1 ! 5,1,-1
call open_sub(jrecl)
end do
contains
subroutine open_sub(irecl)
integer, intent(in) :: irecl
integer :: i
write (*,"(/,' irecl =',i10)") irecl
open (unit=in_unit,file=in_file,action="read",status="old",recl=irecl)
read (in_unit,*) i
write (*,*) "i=",i
close (in_unit)
end subroutine open_sub
end program xrecl

mingw g95 Jun 25 2006 gives

irecl = 4
At line 18 of file xxrecl.f90 (Unit 20 "xrecl.dat")
Traceback: not available, compile with -ftrace=frame or -ftrace=full
Fortran runtime error: Reading more data than the record size (RECL)

and mingw gfortran May 31 2006 gives

irecl = 4
i= 24

irecl = 3
i= 24

irecl = 2
i= 24

irecl = 1
i= 24

For both compilers, the first line in file xrecl.dat contains a space
followed by "24" (no quotes in file), followed by a newline.

Are both compilers conforming to the standard?
 
 
 

recl on g95 and gfortran

Post by Arjen Mark » Thu, 29 Jun 2006 16:00:44


XXXX@XXXXX.COM schreef:


If I read this program correctly, then you are using RECL= on
a file that is not accessed as a direct-access file. I thought
that was only allowed for direct-access?

But if it is allowed, then there could be another explanation:
The unit of RECL is compiler (processor-) dependent. It could
be that g95 uses a single byte as the unit and gfortran uses
a word (4 bytes usually) as the unit. In the latter case, the
record would consist of 4 characters and that is within
the limits of the file you are reading.

Regards,

Arjen

 
 
 

recl on g95 and gfortran

Post by beliavsk » Thu, 29 Jun 2006 21:17:49


Thanks for your reply.

Richard Maine wrote in a 2002 comp.lang.fortran thread
"OPEN(...,RECL=nnn,...) means DIRECT ACCESS, implicitly ?", that in
Fortran 77 it was "illegal to specify recl without also specifying
access="direct".'" but that

'In f90, you can use recl with sequential files, and it means that the
file must support
records at least that long. Note, while we are on the subject, that
specifying recl for a sequential file does *NOT* guarantee that you
won't write records longer than that (for example, it does not
necessarily have any effect on list-directed and namelist I/O, though
it is allowed to). It just means that the file must support records
at least that long. The exact wording of the standard says that
the file is created "with a set of allowed record lengths that
includes the specified value".'

This is consistent with what the Fortran 95 handbook says. So I think
recl is allowed on sequential files in F95.
 
 
 

recl on g95 and gfortran

Post by Michael Me » Thu, 29 Jun 2006 22:33:45


It is (see "Fortran 95/2003 Explained", Section 10.3). I would think that
g95 is entitled to give a run-time error as you're trying to read beyond the
limit of the record that you have, yourself, specified. I would suspect,
too, that this is a little-used feature for sequential files, and so
relatively unexplored.

Regards,

Mike Metcalf
 
 
 

recl on g95 and gfortran

Post by nospa » Fri, 30 Jun 2006 04:11:47


Sorry to disagree with you MIke, but recl= on a sequentai file does not
specify a record length. It specifies that the file must support records
at leat that long. It definitely does not specify that the records must
be exactly that long - that is, no this does not specify a record length
- just a capability of the file. Nor does it specify that records can't
be longer than that.

I can imagine it doing things like selecting between file record
formats. For example, many current compilers use 4-byte record length
headers in unformatted sequential files. On a compiler that wanted to
support those same 4-byte headers for compatibility (or just for the
space savings), but also wanted to support 8-byte fields for large
records, the recl= field in the OPEN could be used to select between
these forms. I don't know of any compilers that use it like that, but
that's the kind of usage I can imagine.


Relatively, yes, but not extremely rare. I've seen it use a fair amount,
particularly in order to override the unreasonably small default limits
that som early f90 compilers used to have. I think most of the f90
compilers today have default limits of 2gb or so, but I definitely
recall default limits as low as 2048 bytes, and there might have been
some lower. Using recl= in the OPEN was common advice for getting around
such small defaults.

Oh, and in answer to another question, no the units of measure are not
the issue. The units of measure for formatted files (which this one is)
are always characters of default kind. Only for unformatted files is it
processor-dependent - and I mean "unformatted" literally; I do not use
that as a sloppy synonym for "list-directed".

I didn't study the sample super carefully, but it off-hand looks like a
g95 bug to me. The other compiler looks ok because, as mentioned above,
recl= doesn't guarantee that record sizes can't be larger than that; it
just guarantees that they can be at least that large. The "at least"
part is really, really important.

--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain
 
 
 

recl on g95 and gfortran

Post by Joos » Fri, 30 Jun 2006 04:20:13

> Oh, and in answer to another question, no the units of measure are not

but could it be that for example the newline (i.e. 4th character in the
file) is considered 'different' from the other 3 characters (e.g.
record terminator or some thing like that ?)

Joost
 
 
 

recl on g95 and gfortran

Post by nospa » Fri, 30 Jun 2006 05:06:48


No.

The newline is not part of the record at all. That is just part of the
system's way of forming records. To Fortran, the record consists of the
data in the record - not the system-dependent way of packaging the
record. There aren't 4 characters in the record in question - only 3.
But there is nothing wrong with having a 3-character sequential record
when recl is 4. There might be something wrong with having a 5-character
one; that would be up to the compiler. But there is nothing at all wrong
with having a 3-character one.

--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain
 
 
 

recl on g95 and gfortran

Post by robert.cor » Fri, 30 Jun 2006 11:43:35


Years ago, Sun's Fortran team considered doing exactly that. The
team did not agree to that implementation, but it was a serious
proposal.

The team considered three serious proposals for implementing large
sequential unformatted records, each supported by about an equal
number of people. As a result, none of the proposals were approved.
Had there been only two proposals, one would have won on a simple
majority vote. Committees are wonderful things.

Bob Corbett
 
 
 

recl on g95 and gfortran

Post by robert.cor » Fri, 30 Jun 2006 11:51:56


I used a Fortran implementation which included the newline character as
part of direct formatted records. That implementation would cause an
error condition to occur when a record of four characters, not
including
the newline, was written to to a file opened with RECL=4. I believe
that
the Fortran 95 standard allows such behavior (see Section 9.4.3 of the
Fortran 95 standard). Based on my experience with J3, my guess is
that J3 would consider that a QoI issue.

Bob Corbett
 
 
 

recl on g95 and gfortran

Post by nospa » Fri, 30 Jun 2006 13:09:16

lt; XXXX@XXXXX.COM > wrote:


Bob often notes subtle points that escape me (and lots of others :-))
until they are elaborated in moe detail, so maybe I'm missing one of
those here; in fact, the odds of that seem good. But....

I mostly disagree.

I don't see how 9.4.3 is even relevant (which probably means I've missed
one of Bob's subtle points). That is about what happens if you get an
error, end-of file, or end-of-record condition. It doesn't say anything
about what the record length is.

On the other hand, the I/O stuff has such huge "outs" that a vendor who
wants to "play the game" can argue that almost anything is standard
conforming. I suppose one could then say that this means that doing
anything in I/O right is a quality of implementation issue in some
sense. I think it more accurate to consider such arguments specious and
not worth debating.

Oh, for those who don't know what I'm talking about, the biggest out is
that the standard allows the compiler to disallow anything that isn't
supported by the device in question. While this is intended to cover
such things as prohibiting reads from a line printer (the old-fangled
ones that you couldn't read from; not these new things where the concept
can actually be sensible), the phrasing is vague enough for a
sufficiently perverse vendor to argue that nothing is supported and
therefore that a program that does any I/O is non-conforming. There even
exist embedded systems where that argument makes sense, but if you are
working on one of those, it will be obvious to you why it makes sense
and you wouldn't be trying to do I/O. Anyway... The compiler can then do
"anything" with the "non-conforming" program. That "anything" can
include acting almost like the standard says, but with whatever
difference the vendor was arguing for. But that stuff aside.

I'd think a more cogent reference is 9.1.1, which says that the length
of a formatted record depends primarily on the number of characters in
the record, but may also depend on the processor and the external
medium. I think this is intended to cover things like processors that
can't support records of arbitrary length. For example, record lengths
might be required to be an even number of 32-bit words, so that a record
with 5 characters (in the real record - not any newline stuff) would
have to be padded out to 8.

But I suppose a vendor could use that clause as an excuse to say that
the record length is always 1 more than the number of characters in the
record.

Ok. In that sense I agree with Bob that it is a quality of
implementation issue. But frankly, I think that's not a lot better
argument than that doing any I/O at all is a quality of implementation
issue. It makes for an amusing academic excercise finding the part of
the standard that can be used to excuse it, but I advise users not to
accept that as an answer any more than they would accept "doing I/O is a
quality of implementation issue" as an answer. That's just broken.

If I had a vendor give me that as a reposnse to the bug report, I'd put
it down as an unacceptable response. Not that this would necesssarily
have any direct result, but I'd sure tell anyone who asked for advice
about the vendor that they refused to fix a trivially fixable violation
of the standard. And I'd call it a violation of the standard, just like
I'd call omitting all I/O a violation of the standard. So sue me. :-)

--
Richard Maine
 
 
 

recl on g95 and gfortran

Post by UHAP02 » Sun, 02 Jul 2006 01:01:39


: > I would suspect,
: > too, that this is a little-used feature for sequential files, and so
: > relatively unexplored.

: Relatively, yes, but not extremely rare. I've seen it use a fair amount,
: particularly in order to override the unreasonably small default limits
: that som early f90 compilers used to have. I think most of the f90
: compilers today have default limits of 2gb or so, but I definitely
: recall default limits as low as 2048 bytes, and there might have been
: some lower. Using recl= in the OPEN was common advice for getting around
: such small defaults.

Agreed. A case in point: Under Alpha VMS F90 (V7.5) anything over 133
columns will fail by default.

eg.
write (6,'(150(''x''))')
fails with;

%FOR-F-OUTSTAOVE, output statement overflows record
unit 6 file SYS$OUTPUT:.;

but;

open (unit=6,file='sys$output',recl=150)
write (6,'(150(''x''))')

works fine. The same situation applies when the destination is a
(new) file too.

Tom.
--
Tom Crane, Dept. Physics, Royal Holloway, University of London, Egham Hill,
Egham, Surrey, TW20 0EX, England.
Email: T.Crane at rhul dot ac dot uk
Fax: +44 (0) 1784 472794
 
 
 

recl on g95 and gfortran

Post by robert.cor » Sun, 02 Jul 2006 12:05:37


For Sun f90/f95, the default record length for the units
connected to standard input, standard output and
standard error is 81. However, the record length
associated with a sequential formatted file is ignored
on input and is mostly ignored on output. The record
length is used to decide when to start a new record
for list-directed and namelist output.

Bob Corbett
 
 
 

recl on g95 and gfortran

Post by UHAP02 » Wed, 05 Jul 2006 05:35:35


: > Agreed. A case in point: Under Alpha VMS F90 (V7.5) anything over 133
: > columns will fail by default.

: For Sun f90/f95, the default record length for the units
: connected to standard input, standard output and
: standard error is 81. However, the record length
: associated with a sequential formatted file is ignored
: on input and is mostly ignored on output. The record
: length is used to decide when to start a new record
: for list-directed and namelist output.

VMS layered products, naturally have RMS to contend with :-{.

Tom.

--
Tom Crane, Dept. Physics, Royal Holloway, University of London, Egham Hill,
Egham, Surrey, TW20 0EX, England.
Email: T.Crane at rhul dot ac dot uk
Fax: +44 (0) 1784 472794
 
 
 

recl on g95 and gfortran

Post by Jan Vorbrg » Thu, 13 Jul 2006 18:55:07

> Years ago, Sun's Fortran team considered doing exactly that. The

So what do the current Sun compilers _do_ in this regard?

Jan
 
 
 

recl on g95 and gfortran

Post by robert.cor » Sat, 15 Jul 2006 13:35:47


Sun f90/f95 currently restricts the size of sequential unformatted
records to be less than 2,147,483,648 bytes. Files can be
larger, but individual records cannot. When Sun's Fortran
product team deadlocked, the product team said that the
engineering team should wait for significant customer demand
before implementing large sequential unformatted records.
I expected such demand to develop long before it did.

I suspect that some of the members of the product team hoped
that a defacto standard way of implementing large records
would emerge before we had to deal with the issue. That has
not happened. Therefore, in addition to handling our form of
large records, we are faced with the prospect of having to
support our major competitors' formats as well. For structures,
there is little hope of compatibility in any case, but for scalars
and arrays of simple types, we should be able to manage.

Bob Corbett