[all-commits] [llvm/llvm-project] 4d42e1: [flang] runtime: fix problems with I/O around EOF ...

[Peter Klausler via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 4d42e16eb8f7bb1484a1970324aa3391809188de
      https://github.com/llvm/llvm-project/commit/4d42e16eb8f7bb1484a1970324aa3391809188de
  Author: peter klausler <pklausler at nvidia.com>
  Date:   2021-07-23 (Fri, 23 Jul 2021)

  Changed paths:
    M flang/docs/Extensions.md
    M flang/runtime/edit-input.cpp
    M flang/runtime/edit-output.cpp
    M flang/runtime/unit.cpp
    M flang/unittests/RuntimeGTest/Namelist.cpp

  Log Message:
  -----------
  [flang] runtime: fix problems with I/O around EOF & delimited characters

When a WRITE overwrites an endfile record, we need to forget
that there was an endfile record.  When doing a BACKSPACE
after an explicit ENDFILE statement, the position afterwards
must be upon the endfile record.

Attempts to join list-directed delimited character input across
record boundaries was due to a bad reading of the standard
and has been deleted, now that the requirements are better understood.
This problem would cause a read attempt past EOF if a delimited
character input value was at the end of a record.

It turns out that delimited list-directed (and NAMELIST) character
output is required to emit contiguous doubled instances of the
delimiter character when it appears in the output value.  When
fixed-size records are being emitted, as is the case with internal
output, this is not possible when the problematic character falls
on the last position of a record.  No two other Fortran compilers
do the same thing in this situation so there is no good precedent
to follow.

Because it seems least wrong, with this patch we now emit one copy
of the delimiter as the last character of the current record and
another as the first character of the next record.  (The
second-least-wrong alternative might be to flag a runtime error,
but that seems harsh since it's not an explicit error in the standard,
and the output may not have to be usable later as input anyway.)
Consequently, the output is not suitable for use as list-directed or
NAMELIST input.

If a later standard were to clarify this case, this behavior will of
course change as needed to conform.

Differential Revision: https://reviews.llvm.org/D106695