Fortran limitation on output file line length?

[AONym]

I am having a problem with Fortran inserting CR/LF into `WRITE` output to a sequential, formatted  file.

The file is opened with

    OPEN(UNIT = ioFile, FILE = outputFilePath, STATUS = statusWanted, POSITION = positionWanted, IOSTAT = openErr)
	INQUIRE (UNIT = ioFile, RECL=recLen)

To debug, I added the INQUIRE statement; recLen is set to 132, obviously not what I want.

The file is being written by

        WRITE(ioFile, "(/3X, A10, A1, F11.5, 2X, 19(A1, 3X, A10, A1, F11.5, 2X))") &
            xHdr, sep, radiusInclude(1), &
            (sep, xHdr, sep, radiusInclude(iRadialPoint), iRadialPoint = 2, nRadialPointInclude)

Examination of the output file with Notepad shows a line break has been added at character position 635 of the long line (nRadialPointInclude is large). This is not Notepad line-wrapping; examination of the file with a hex viewer shows the unwanted characters 0D, 0D, 0A added at position 558. The difference between Notpad's result and the hex viewer is due to the character 'sep' being tab.

So what I want to know is, what is the limit of Fortran runtime's length for a single formatted line, and how can I increase it?

Windows 11, Fortran Classic 2023,2 Visual Studio 2022

[IanH · Accepted solution]

How big is "large" with respect to nRadialPointInclude?  If it is bigger than 20, then the provided write format runs out of items, language rules then say "use format reversion and start a new record".

For an unlimited repeat count, use (...2X,*(A1,3X,...)).

Technically, to avoid some arbitrary maximum record length you need to use stream access.  Practically, on Fortran processors running on hardware of today, sequential access will also get you unlimited record lengths, though a program that writes more than whatever is the RECL for the connection (if not specified in the OPEN statement then this is a processor dependent value - looks like it is 132 for Intel Fortran!) is non-conforming (F2023 12.6.4.5p10).

[AONym]

@IanH: Tnx. This was the solution to my immediate problem.

I think you are saying that I could make my code conforming by opening the output file with RECL=my desired limit, rather than depend on Intel's choice to allow the non-conforming code. Is that your view?

[IanH]

My view is to not bother with specifying RECL.  The code will be technically non-conforming, but there is no practical significance.  If it still bothered me, I would just switch to stream access (saves me having to work out what the maximum RECL needed to be!).