This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug fortran/45710] Adjust format and padding for WRITE of NAMELIST group to internal file
- From: "urbanjost at comcast dot net" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 22 Sep 2010 05:19:41 -0000
- Subject: [Bug fortran/45710] Adjust format and padding for WRITE of NAMELIST group to internal file
- References: <bug-45710-18131@http.gcc.gnu.org/bugzilla/>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- Comment #11 from urbanjost at comcast dot net 2010-09-22 05:19 -------
Subject: Re: Adjust format and padding for WRITE of NAMELIST group to internal
file
Great! Although I (too?) find the f2008 reference a little confusing on
whether the line beginning the NAMELIST output
needs to have column 1 clear, I found the XL IBM on-line Fortran manual
shows the & in column two; and the case where
the output might all be on one line is clearer if column 1 is clear; and the
history behind column one being special for ASA carriage-control (still
available on VMS/OpenVMS and via commands like asa(1), even if no longer
common) made me lean towards asking for it to be shifted (along with the
cited line from the f2008 reference). Plus, it is clear that column 1 can be
clear if desired (Arbitrary numbers of spaces are allowed to precede the &
the way I read the standard). So I would still prefer the & to start in
column 1, but I can understand someone not
being convinced that it is required; and it does seem more asthetically
pleasing in column 1.
Since it is stated in the standard that column one is used by a continued
character string, allowing it to have the & is not going to complicate
things much further; and the standard doesn't specify many other things in a
way that I'm sure about the meaning yet (should output be "wrapped" to the
length of the internal file record lengths when a string exceeds the
internal file record
length or is it OK to cast an error indicating the record length is
exceeded; exactly which delimiter is the default for strings; is "stream
I/O" format supported for internal files; ...?) I can see
either interpretation at this point.
Adding the record with blanks solves a real issue I encountered; and
the initial problem I saw was already addressed in 4.6.0 so I'm happy and
just want to say "Thanks!".
_________________________________________________________
NAMELIST output example from the IBM manual (column 1 is not used)
1 2 3 4
1...+....0....+....0....+....0....+....0
&NL1
I=12046, J=12047, C=BACON, SMITH=20, John Smith
/
_________________________________________________________
----- Original Message -----
From: "jvdelisle at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org>
To: <urbanjost@comcast.net>
Sent: Tuesday, September 21, 2010 10:52 PM
Subject: [Bug fortran/45710] Adjust format and padding for WRITE of NAMELIST
group to internal file
>
>
> ------- Comment #10 from jvdelisle at gcc dot gnu dot org 2010-09-22
> 02:52 -------
> Created an attachment (id=21860)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21860&action=view)
> --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21860&action=view)
> Tentative patch, not regression tested
>
> Our interpretation of this:
>
> 3 An ampersand character followed immediately by a namelist-group-name
> will be produced by namelist formatting at the start of the first
> output record to indicate which particular group of data objects is
> being output. A slash is produced by namelist formatting to indicate
> the end of the namelist formatting.
>
> Is no space on the first line. I would like to leave it that way for now.
> Attached patch fixes the padding.
>
>
> --
>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45710
>
> ------- You are receiving this mail because: -------
> You reported the bug, or are watching the reporter.
>
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45710