Reading more data than recl should allow

[Ondrej_K_]

Say I have the following code (saved as mf.f90, so it's reading itself)

program recltest ! this is a longer string
  implicit none

  integer :: ios
  character(len=100) :: line
  
  open(unit=101, iostat=ios, action='READ', form='FORMATTED', recl=4, file='mf.f90')

  read(101, '(A)', iostat=ios) line
  print *, line

end program recltest

I would expect "prog" to be printed, which is what gfortran-compiled binary does. But when compiled with the newest Intel Visual Fortran compiler, I get the whole line. Can you please explain if I'm misunderstanding the 'recl' argument?

Thank you!

[TimP]

By default , ifort takes recl =4 as 16 bytes.  Compile option standard-semantics or assume byterecl will reconcile that difference with gfortran.

[Ondrej_K_]

Alright, but then why do I get the whole line (clearly more than 16 bytes)? I tried setting recl to various values, but it didn't change the outcome. It seems to me that when variable length > recl (or recl*4), ifort will prefer to fill the variable. But I may be misunderstanding something very basic.

[Arjen_Markus]

Hm, you specify a record length for a file with sequential access and you read it without reference to a particular record. I am not sure what the standard says on this type of usage.
 

[Steven_L_Intel1]

The standard says, " RECL= specifier shall be positive. It specifies the length of each record in a file being connected for direct access, or specifies the maximum length of a record in a file being connected for sequential access." So here it says that the maximum length of the record is 4 bytes. However, there's nothing in the standard that says this constrains a sequential input. The only thing I can spot is a restriction on the programmer that on a sequential output statement the statement "shall not specify more characters for a record than have been specified by a RECL= specifier in the OPEN statement or the record length of an internal file."

The standard does say "During advancing input when the pad mode has the value NO, the input list and format specification shall not require more characters from the record than the record contains." The record contains more than 4 characters but RECL says the maximum is 4. My take on this is that the program is nonconforming, since the READ tries to transfer 100 characters, and that either behavior is acceptable.

[Les_Neilson]

The online help for OPEN : RECL specifier states

"If the file is connected for formatted data transfer, the value must be expressed in bytes (characters)."

From the code shown the file is opened for FORMATTED read and therefore recl=4 should be specifying 4 bytes.

The help goes on to say "If you read a fixed-length file with a record length different from the one used to create the file, indeterminate results can occur." I don't know whether that applies in this case.

Les

[mecej4]

Les Neilson wrote:

The online help for OPEN : RECL specifier states

"If the file is connected for formatted data transfer, the value must be expressed in bytes (characters)."

From the code shown the file is opened for FORMATTED read and therefore recl=4 should be specifying 4 bytes.

Agreed.

The help goes on to say "If you read a fixed-length file with a record length different from the one used to create the file, indeterminate results can occur." I don't know whether that applies in this case.

I found the quoted text in the section "File operation I/O statements - Open statement specifiers - RECL specifier". Should it not say "fixed record-length file" instead of "fixed-length file"? The file size is not relevant to this discussion.

The file in question is a text file, and so will almost always contain variable length records. The RECL specified should be large enough to cover the maximum record length and, if not, there may be a risk of buffer overflow and it would be helpful if the IOSTAT value returned after the READ statement had a value that said "Buffer too small" something similar.

[Les_Neilson]

mecej4 wrote:

Quote:

The help goes on to say "If you read a fixed-length file with a record length different from the one used to create the file, indeterminate results can occur." I don't know whether that applies in this case.

I found the quoted text in the section "File operation I/O statements - Open statement specifiers - RECL specifier". Should it not say "fixed record-length file" instead of "fixed-length file"? The file size is not relevant to this discussion.

The file in question is a text file, and so will almost always contain variable length records. The RECL specified should be large enough to cover the maximum record length and, if not, there may be a risk of buffer overflow and it would be helpful if the IOSTAT value returned after the READ statement had a value that said "Buffer too small" something similar.

Yes I too thought the wording a little strange.

Re-reading the OP I see that it is reading the source file so yes they would most likely be variable length records.

Les