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 *_*
