(This is an attempt to reply to a Mon Feb 3 19:09:38 GMT 2025 message by Steve Kargl.)
> I believe that you are misreading C1223. The file is > opened with form='unformatted'. Hm, okay. I guess it comes down to whether you "diagram" the sentence in the spec as "An ADVANCE= specifier shall appear only in a formatted (sequential or stream) data transfer statement" or "An ADVANCE= specifier shall appear only in a (formatted sequential) or (stream data transfer) statement". If you interpret it the first way the gfortran behavior is correct (although the error message could be improved…), if you interpret it the second way gfortran is incorrect. > PS: You're looking for the INQUIRE statement. In the context of the program I was trying to write, INQUIRE can be used to get the byte length of the file. That is not something I was trying to do. The data was structured, and needed to be parsed to determine the allocation size. In other words INQUIRE is the equivalent of C ftell() and I am looking for the equivalent of C fseek(). (Which the standard appears to only offer through nonadvancing reads… which gfortran appears to disallow for an unformatted stream file. Unless you do the "silly" thing I eventually did, which is to bundle your seek together with the next advancing read.) Thanks for the information. On Mon, Feb 3, 2025 at 1:34 PM Andi McClure <andi.m.mccl...@gmail.com> wrote: > Last week, as an exercise in learning FORTRAN, I did a programming puzzle > ( https://adventofcode.com/2024/day/4 ) with gfortran. I targeted the > 2023 standard (*not* GNU). I saw two oddities. The first I posted about in > this mailing list already (and it turns out there is a relevant bugzilla > bug). The other I *think* is a bug (and I am not finding an existing > bugzilla bug on my own), but I am less sure, so wanted to check here first > before filing. > > For my solution, I needed to read in a file in stream mode, character by > character(1). I needed to do this twice, once to find out what size array > to load the data into and once to load the data into my newly-allocated > array. It initially appeared stream mode would allow me to do this without > closing and reopening the file, by "seeking" back to the beginning of the > file using the pos= argument to READ. But when I tried to do this, > something odd happened. > > Details: I open the file with > > ``` > > open(10,file=path,access='stream',form='unformatted',action='read',iostat=file_error) > ``` > > This works; scanning to determine the input size works. Now I need to > seek. I find this old stackoverflow answer: > https://stackoverflow.com/a/11785795 > > Claiming that the following code works (and implying they tested it in " > ifort"): > > ``` > READ (iu,"()", ADVANCE='NO', POS=file_pos) ! iu is file unit > ``` > > I created a test program implementing this: > > > https://github.com/mcclure/aoc2024/blob/38875a77fd48d8208ebcadfb3ec9c53fb722ef8b/04-01-wordsearch/src/puzzle.f90#L4 > > And using a test input such as: > > > https://github.com/mcclure/aoc2024/blob/38875a77fd48d8208ebcadfb3ec9c53fb722ef8b/04-01-wordsearch/data/sample-2.18.txt > > I can run it with `gfortran src/puzzle.f90 -std=f2023 -o program && > ./program data/sample-2.18.txt`. When I do this, I get a failure: > > ``` > At line 88 of file src/puzzle.f90 (unit = 10, file = > 'data/sample-2.18.txt') > Fortran runtime error: Format present for UNFORMATTED data transfer > ``` > > It appears it does not like the "()" format. However, imagine I edit line > 88 to change `read(10, "()", advance='no', pos=1)` to `read(10, > advance='no', pos=1)`, removing the format. Now I get a different error: > > ``` > ./program data/sample-2.18.txt > src/puzzle.f90:88:21: > > 88 | read(10, advance='no', pos=1) > | 1 > Error: the ADVANCE= specifier at (1) must appear with an explicit format > expression > ``` > > So if I have a (null) format specifier the error message tells me to > remove the format expression, and if I remove the format specifier the > error message tells me to add a format expression. There appears to be *no > way* of using advance='no' that will not cause gfortran to emit an error; > even putting in a (spurious/useless) read, such as with `read(10, "(a)", > advance='no', pos=1) char_in`, produces "Fortran runtime error: Format > present for UNFORMATTED data transfer". > > I do not have a specific need for this to be fixed; I eventually got my > program to work via a workaround I would consider "silly" ( see line 102: > https://github.com/mcclure/aoc2024/blob/ca77f141f33ab494dc1bb43f3d6f13e775a36303/04-01-wordsearch/src/puzzle.f90#L102 > ). However it seems like there is a bug here, for three reasons: because > having some method of seeking the file without simultaneously doing a read > is fundamentally desirable; because the error messages seem to give > misleading directions; and because I *think* this is a standard > nonconformance. > > If I look at the current standard ( 2023 draft document: > https://j3-fortran.org/doc/year/23/23-007r1.pdf ) under the definition of > io-control-spec I see; > > > C1223 (R1213) An ADVANCE= specifier shall appear only in a formatted > sequential or stream data transfer25 > > statement with explicit format specification (13.2) whose > io-control-spec-list does not contain an internal-26 > > file-variable as the io-unit. > > This implies an io-control-spec-list with *no* "io-unit" should be > allowed. I find this same text (with different numbering) in drafts of the > 2008 and 2003 standards, so it appears this has been part of FORTRAN as > long as stream mode itself. > > Does anyone know of an impediment to filing this (am I doing something > wrong, is there an existing bug I was not able to find(2))? > > --- > > (1) I understand use of stream mode is considered unusual. The problem I > was solving here was a rare case it was actually appropriate: the input > file, linked above as "test input", was a grid of ASCII art. > > (2) I think I have the hang of using the mailing list now, so I expect I > will actually see the reply this time *_* >
