public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "burnus at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug fortran/52251] New: Nonadvancing I/O and the t edit descriptor
Date: Tue, 14 Feb 2012 20:11:00 -0000	[thread overview]
Message-ID: <bug-52251-4@http.gcc.gnu.org/bugzilla/> (raw)

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52251

             Bug #: 52251
           Summary: Nonadvancing I/O and the t edit descriptor
    Classification: Unclassified
           Product: gcc
           Version: 4.7.0
            Status: UNCONFIRMED
          Keywords: wrong-code
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: burnus@gcc.gnu.org
                CC: jvdelisle@gcc.gnu.org


From
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/5eff88b12c9bd24f

gfortran (and sunf95) print for the following program: "Hello", starting in
column 1. However, other compilers (g95, ifort, NAG, PathScale, Open64,
crayftn, pgf95) print "Hello" in column 25.

   Write( *, '( t25 )', Advance = 'No' )
   Write( *, '( "Hello" )' ) 

Richard Maine thinks that gfortran's version is correct, but he fails to nail
it in the standard and is a bit unsure. Dick Hendrickson thinks the other
compilers are correct. Seems to make sense to fill an interpretation request.

Glancing at the standard, I am inclined to the interpretation that there should
be blanks.


 * * *


From the Fortran 2008 standard:


"9.3.4.2 Advancing and nonadvancing input/output"
[...]
"A nonadvancing input/output statement may position a record file at a
character position within the current record, or a subsequent record (10.8.2).
Using nonadvancing input/output, it is possible to read or write a record
of the file by a sequence of input/output statements, each accessing a portion
of the record. It is also possible to read variable-length records and be
notified of their lengths. If a nonadvancing output statement leaves a file
positioned within a current record and no further output statement is executed
for the file before it is closed or a BACKSPACE, ENDFILE, or REWIND statement
is executed for it, the effect is as if the output statement were the
corresponding advancing output statement."


"10.5 Positioning by format control

After each data edit descriptor or character string edit descriptor is
processed, the file is positioned after the last character read or written in
the current record.

After each T, TL, TR, or X edit descriptor is processed, the file is positioned
as described in 10.8.1. [...]"


"10.8.1 Position editing
The T, TL, TR, and X edit descriptors specify the position at which the next
character will be transmitted to or from the record. If any character skipped
by a T, TL, TR, or X edit descriptor is of type nondefault character, and the
unit is a default character internal file or an external non-Unicode file, the
result of that position editing is processor dependent.

The position specified by a T edit descriptor may be in either direction from
the current position. [...]
[...]
On output, a T, TL, TR, or X edit descriptor does not by itself cause
characters to be transmitted and therefore does not by itself affect the length
of the record. If characters are transmitted to positions at or after the
position specified by a T, TL, TR, or X edit descriptor, positions skipped and
not previously filled are filled with blanks. The result is as if the entire
record were initially filled with blanks.

On output, a character in the record may be replaced. However, a T, TL, TR, or
X edit descriptor never directly causes a character already placed in the
record to be replaced. Such edit descriptors may result in positioning such
that subsequent editing causes a replacement.

10.8.1.1 T, TL, and TR editing

The left tab limit affects file positioning by the T and TL edit descriptors.
Immediately prior to nonchild data transfer (9.6.4.8.2), the left tab limit
becomes defined as the character position of the current record or the current
position of the stream file. If, during data transfer, the file is positioned
to another record, the left tab limit becomes defined as character position one
of that record.

The Tn edit descriptor indicates that the transmission of the next character to
or from a record is to occur at the nth character position of the record,
relative to the left tab limit."


[Informative]
"C.6.2 Nonadvancing input/output (9.3.4.2)

Data transfer statements affect the positioning of an external file. In Fortran
77, if no error or end-of-file condition exists, the file is positioned after
the record just read or written and that record becomes the preceding record.
This part of ISO/IEC 1539 contains the record positioning ADVANCE= specifier in
a data transfer statement that provides the capability of maintaining a
position within the current record from one formatted data transfer statement
to the next data transfer statement. The value NO provides this capability. The
value YES positions the \fle after the record just read or written. The default
is YES.

The tab edit descriptor and the slash are still appropriate for use with this
type of record access but the tab cannot reposition before the left tab limit.
[...]
In an implementation of nonadvancing input/output in which a nonadvancing write
to a terminal device causes immediate display of the output, such a write can
be used as a mechanism to output a prompt.
[...]
This part of ISO/IEC 1539 does not require that an implementation of
nonadvancing input/output operate in this manner. For example, an
implementation of nonadvancing output in which the display of the output is
deferred until the current record is complete is also standard-conforming. Such
an implementation will not, however, allow a prompting mechanism of this kind
to operate."


             reply	other threads:[~2012-02-14 20:11 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-02-14 20:11 burnus at gcc dot gnu.org [this message]
2012-02-14 20:30 ` [Bug fortran/52251] " burnus at gcc dot gnu.org
2012-02-15  7:19 ` burnus at gcc dot gnu.org
2012-02-15 10:11 ` burnus at gcc dot gnu.org
2015-04-23 19:46 ` jvdelisle at gcc dot gnu.org

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bug-52251-4@http.gcc.gnu.org/bugzilla/ \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).