public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "jvdelisle at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug fortran/99711] Crash when reading an allocated character array in namelist Date: Tue, 23 Mar 2021 01:11:10 +0000 [thread overview] Message-ID: <bug-99711-4-SPAs6uCTMJ@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-99711-4@http.gcc.gnu.org/bugzilla/> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99711 Jerry DeLisle <jvdelisle at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jvdelisle at gcc dot gnu.org Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #1 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> --- F2018 standard section 13.10.3 List-directed Input There is a note NOTE 13.29 at the end of the first sub-section 13.10.3.1" "An allocatable, deferred-length character effective item does not have its allocation status or allocated length changed as a result of list-directed input." This implies that if the strings of the array are not already allocated to a resonable length, for example a string of blanks, then the read will attempt to transfer the file contents into unallocated strings. If the status is unallocated the list READ cannot do any allocation to change its status to ALLOCATED. Thus all bets are off if it crashes. The read routines have no idea of the size to allocate the length to until the read is completed. There may be other places in the standard to clarify this, but looks like invalid fortran.
next prev parent reply other threads:[~2021-03-23 1:11 UTC|newest] Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-03-22 14:02 [Bug fortran/99711] New: " phil1691 at gmail dot com 2021-03-23 1:11 ` jvdelisle at gcc dot gnu.org [this message] 2021-03-23 2:11 ` [Bug fortran/99711] " kargl at gcc dot gnu.org 2021-03-23 2:29 ` jvdelisle at gcc dot gnu.org 2021-03-23 2:41 ` jvdelisle at gcc dot gnu.org 2021-03-23 6:16 ` sgk at troutmask dot apl.washington.edu 2021-03-23 7:37 ` philippe.wautelet at aero dot obs-mip.fr 2021-03-24 2:41 ` jvdelisle at gcc dot gnu.org 2021-03-24 3:15 ` jvdelisle at gcc dot gnu.org 2021-03-24 5:35 ` sgk at troutmask dot apl.washington.edu 2021-03-24 5:45 ` sgk at troutmask dot apl.washington.edu 2021-03-25 3:32 ` jvdelisle at gcc dot gnu.org 2021-03-26 1:47 ` jvdelisle at gcc dot gnu.org 2021-03-26 2:25 ` jvdelisle at gcc dot gnu.org 2021-03-26 2:38 ` jvdelisle at gcc dot gnu.org 2021-03-26 6:04 ` sgk at troutmask dot apl.washington.edu 2021-03-26 23:38 ` jvdelisle at gcc dot gnu.org 2021-03-27 3:14 ` jvdelisle at gcc dot gnu.org 2023-08-31 12:58 ` philippe.wautelet at aero dot obs-mip.fr 2023-08-31 17:20 ` sgk at troutmask dot apl.washington.edu 2023-08-31 17:22 ` kargl 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-99711-4-SPAs6uCTMJ@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: linkBe 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).