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/53796] New: I/O INQUIRE of RECL:  If not specified in OPEN,  the default value should be returned (sequential access)
Date: Thu, 28 Jun 2012 10:26:00 -0000	[thread overview]
Message-ID: <bug-53796-4@http.gcc.gnu.org/bugzilla/> (raw)

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

             Bug #: 53796
           Summary: I/O INQUIRE of RECL:  If not specified in OPEN,  the
                    default value should be returned (sequential access)
    Classification: Unclassified
           Product: gcc
           Version: 4.8.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: burnus@gcc.gnu.org
                CC: jvdelisle@gcc.gnu.org
        Depends on: 44292


As reported at
http://www.rhinocerus.net/forum/lang-fortran/708936-inquire-get-maximum-record-length-bug-gfortran.html


One has to distinguish three cases:
- Direct access: The RECL= has to be given in OPEN
- Stream access: No RECL= is allowed in OPEN
- Sequential access: RECL= can be given in OPEN, otherwise the default is used.

gfortran handles the case of RECL= given in OPEN correctly by returning that
value and it handles stream access by using -1. (As the argument becomes
undefined, any value would do.)

Additionally, gfortran always returns -1 for sequential access instead of
returning the default value.


The question is only how to handle sequential access. We have two questions:

a) gfortran handles (on most systems) large files, i.e. the default value would
be larger than huge(0). Additionally, (cf. PR 44292) gfortran does not handle
INT64  variables for RECL. Thus, which value should be returned?
HUGE(kind(recl_var))?

b) What should happen if the user exceeds the RECL= specified in OPEN.
(Possibly, that's handled correctly, but I want to add it to the to-do list for
checking.) - That is also related to the question of (a): Handling INQUIRE
RECL=int32_var.


>From the Fortran 2008 standard at "9.10.2.26 RECL= specifier in the INQUIRE
statement":

"The scalar-int-variable in the RECL= specifier is assigned the value of the
record length of a connection for direct access, or the value of the maximum
record length of a connection for sequential access. If the connection is for
formatted input/output, the length is the number of characters for all records
that contain only characters of default kind. If the connection is for
unformatted input/output, the length is measured in file storage units. If
there is no connection, or if the connection is for stream access, the scalar
int-variable becomes undefined."


For OPEN, the following applies:

"The value of the RECL= specifier shall be positive. It specifies the length of
each record in a file being connected for direct access, or specifies the
maximum length of a record in a file being connected for sequential access.
This
specifier shall not appear when a file is being connected for stream access.
This specifier shall appear when a file is being connected for direct access.
If this specifier is omitted when a file is being connected for sequential
access, the default value is processor dependent. If the file is being
connected for formatted input/output, the length is the number of characters
for all records that contain only characters of default kind. When a record
contains any nondefault characters, the effect of the RECL= specifier is
processor dependent. If the file is being connected for unformatted
input/output, the length is measured in file storage units. For an existing
file, the value of the RECL= specifier shall be included in the set of allowed
record lengths for the \fle. For a new file, the processor creates the file with
a set of allowed record lengths that includes the specified value."


             reply	other threads:[~2012-06-28 10:26 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-06-28 10:26 burnus at gcc dot gnu.org [this message]
2012-06-28 15:42 ` [Bug fortran/53796] " burnus at gcc dot gnu.org
2012-06-28 18:22 ` clivegpage at gmail dot com
2012-06-29  9:56 ` jvdelisle at gcc dot gnu.org
2012-06-29 10:00 ` clivegpage at gmail dot com
2012-06-29 10:07 ` burnus at gcc dot gnu.org
2012-06-29 10:13 ` jvdelisle at gcc dot gnu.org
2012-06-29 13:29 ` burnus at gcc dot gnu.org
2012-06-29 15:05 ` burnus at gcc dot gnu.org
2012-06-29 23:43 ` jvdelisle at gcc dot gnu.org
2012-06-30  0:32 ` jvdelisle at gcc dot gnu.org
2012-06-30  1:35 ` jvdelisle at gcc dot gnu.org
2012-06-30  8:40 ` clivegpage at gmail dot com
2012-06-30 20:10 ` jb at gcc dot gnu.org
2015-10-20 17:14 ` dominiq at lps dot ens.fr
2015-10-20 17:58 ` jb at gcc dot gnu.org
2015-10-20 18:57 ` dominiq at lps dot ens.fr

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-53796-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).