- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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!
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
By default , ifort takes recl =4 as 16 bytes. Compile option standard-semantics or assume byterecl will reconcile that difference with gfortran.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page