------- Comment #8 from urbanjost at comcast dot net  2010-09-21 09:34 -------
Subject: Re:  WRITE of NAMELIST group to internal file contains newline
characters

Per some discussions today, there were apparently different versions on some 
of the nodes I was using, ranging from 4.3.4 to 4.6.0 (they were all 
supposed to be
identical); so I can't be sure till I get back.

But I installed Cygwin on an MSWindows laptop and upgraded to gfortran 4.6.0 
(per the gfortran -v switch; it comes with gfortran 4.3.4)
and I am getting what you show, which is much better, I looked thru all the 
2009 and 2010 fixes and missed seeing any change like this.

Maybe a few tweeks are in order? Looking at the f2008 draft standard,
 from 10.11.4.3 line 5, taken literally the & should be in column 2 instead 
of 1;
and the records written to in the OUT array should be blank filled to the
end per 9.4 line 2 bullet (d)?  That would be more in line with how 
list-directed
output works (column 1 always being clear) and would prevent "garbage" from
being in the lines written to if OUT is not initialized to all blanks; so I 
think I'm
reading
(interpreting?) the sections correctly.

>From the draft:

  10.11.4.3    Namelist output records

1 If two or more successive values for the same namelist group item in
  an output record produced have identical values, the processor has
  the option of producing a repeated constant of the form r *c instead
  of the sequence of identical values.

2 The name of each namelist group object list item is placed in the
  output record followed by an equals and a list of values of the namelist
  group object list item.

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.

4 A null value is not produced by namelist formatting.

5 Except for new records created by explicit formatting within a defined
  output procedure or by continuation of delimited character sequences,
  each output record begins with a blank character.

   9.4      Internal files

1 Internal files provide a means of transferring and converting data
  from internal storage to internal storage.

2 An internal file is a record file with the following properties.

   (a)· The file is a variable of default, ASCII, or ISO 10646 character
     that is not an array section with a vector subscript.

   (b)· A record of an internal file is a scalar character variable.

   (c)· If the file is a scalar character variable, it consists of a single
     record whose length is the same as the length of the scalar character
     variable. If the file is a character array, it is treated as a
     sequence of character array elements. Each array element, if any,
     is a record of the file. The ordering of the records of the file is
     the same as the ordering of the array elements in the array (6.5.3.2)
     or the array section (6.5.3.3). Every record of the file has the
     same length, which is the length of an array element in the array.

  (d)· A record of the internal file becomes defined by writing the
     record. If the number of characters written in a record is less
     than the length of the record, the remaining portion of the record
     is filled with blanks. The number of characters to be written shall
     not exceed the length of the record.

  (e)· A record may be read only if the record is defined.

   (f)· A record of an internal file may become defined (or undefined)
     by means other than an output statement.  For example, the character
     variable may become defined by a character assignment statement.

   (g)· An internal file is always positioned at the beginning of the
     first record prior to data transfer, except for child data transfer
     statements (9.6.4.7). This record becomes the current record.

   (h)· The initial value of a connection mode (9.5.2) is the value that
     would be implied by an initial OPEN statement without the
     corresponding keyword.

   (i)· Reading and writing records shall be accomplished only by sequential
     access formatted input/output statements.

   (j)· An internal file shall not be specified as the unit in a file
     connection statement or a file positioning statement.


----- Original Message ----- 
From: "jvdelisle at gcc dot gnu dot org" <gcc-bugzi...@gcc.gnu.org>
To: <urbanj...@comcast.net>
Sent: Monday, September 20, 2010 11:20 PM
Subject: [Bug fortran/45710] WRITE of NAMELIST group to internal file 
contains newline characters


>
>
> ------- Comment #7 from jvdelisle at gcc dot gnu dot org  2010-09-21 
> 03:20 -------
> With current trunk, gfortran 4.6, I get:
>
> BEFORE:
> 001  @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
> 002  @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
> 003  @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
> 004  @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
> 005  @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
> AFTER:
> &NL1 @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
> A=  1.0000000    ,@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
> B=  2.0000000    ,@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
> C=  3.0000000    ,@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
> /
>
> I thought I remembered fixing this before. What version of gfortran are 
> you
> using? (I snipped off the ends of the lines above to fit the report.)
>
>
> -- 
>
>
> 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

Reply via email to