Bug 36895 - Namelist writting to internal files: Control characters wrong?
Summary: Namelist writting to internal files: Control characters wrong?
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: fortran (show other bugs)
Version: 4.4.0
: P3 normal
Target Milestone: ---
Assignee: Jerry DeLisle
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-07-22 06:59 UTC by Tobias Burnus
Modified: 2008-08-31 00:13 UTC (History)
3 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2008-07-22 16:47:52


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Tobias Burnus 2008-07-22 06:59:59 UTC
Found at
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/543dbbd5a3cb5fce

Jerry, could you check whether Richard Maine's concerns are correct or not? NAG f95 and g95 write everything in one line; g95 has also a trailing comma, NAG does not. (ifort 11beta and sunf95 don't support nml for internal files, yet.)

For external files, g95 prints a newline before "/". (ifort and sunf95 print also in several lines, but without trailing comma.)


----------------- Richard Maine writes: ------------------------------

> C:\gcc_mingw64a\clf\nakelist>nakelist
>  &STUFF
>  N=        666,  /

That output showed up in the posting as being on two lines (at least in
my newsreader). I hope that was an artifact of the newsgroup posting. If
the compiler actually does something like put control characters (such
as cr and/or lf) in the internal file, then that would be a bug.

Also, the comma looks wrong to me. I don't think it is allowed. I
suppose I'd need to study more carefully to be 100% sure, but the comma
is a separator - not a terminator. That also looks like a bug, and one
less likely to be a posting artifact.
Comment 1 Tobias Burnus 2008-07-22 09:01:49 UTC
"10.10.2 Namelist output"

"The form of the output produced is the same as that required for input, except for the forms of real, character, and logical values. The name in the output is in upper case. With the exception of adjacent undelimited character values, the values are separated by one or more blanks or by a comma, or a semicolon if the decimal edit mode is COMMA, optionally preceded by one or more blanks and optionally followed by one or more blanks."

"The processor may begin new records as necessary."

 * * *

"9.3 Internal files"
"(2) A record of an internal file is a scalar character variable."
"(3) 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."

 * * *

Thus I think Richard is right that having new-line characters is wrong (at least for scalar variables). At least I believe that new-line characters can be regarded as starting a new record.
Comment 2 Jerry DeLisle 2008-07-22 16:47:52 UTC
I will check on this later tonight or this week.  I have wondered about that comma myself.  
Comment 3 Tobias Burnus 2008-07-22 17:47:17 UTC
> I will check on this later tonight or this week.  I have wondered about that
> comma myself.

Thanks! I believe the comma should be valid, even though it is superfluous and "looks wrong". Thus it were nice if one could get rid of it, but only if it is not too much work and does not slow down the I/O.

Regarding the line breaks: I think they are indeed wrong. At the moment I cannot come up with a good example how this can cause problems, but I'm sure one could construct one.

Running the following program using NAG f95 gives the error:
Invalid character '
' in NAMELIST input
Program terminated by I/O error on internal file

Thus NAG f95 does not like the line break. (The program works in g95 and gfortran.)

----------------------
character(len=255) :: str(2)
integer :: i, j(2)
namelist /nm/i,j
i = 44
j = 45
str(1) = ' &NM '//new_line('a')//' I=          1,'
str(2) = ' J= 2*2          ,  /'
read(str,nml=nm)
print *, i, j
end
----------------------
Comment 4 Jerry DeLisle 2008-07-23 01:39:31 UTC
I have reviewed our code.

First, we reject the internal unit for namelist when using -std=f95.

$ gfc -std=f95 pr36895.f90 
pr36895.f90:4.8:

  write(line,nml=stuff)
       1
Error: Fortran 2003: Internal file at (1) with namelist

Second, our namelist write function makes its own cr-lf sequences and does not use next_record so all the checks for end of record are not used.  Normally you can have multiple records with internal units only if it is a character array, one record per array element.

I will fix this.
Comment 5 Jerry DeLisle 2008-08-31 00:05:55 UTC
Subject: Bug 36895

Author: jvdelisle
Date: Sun Aug 31 00:04:33 2008
New Revision: 139813

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=139813
Log:
2008-08-30  Jerry DeLisle  <jvdelisle@gcc.gnu.org>

	PR libfortran/36895
	* io/write.c (namelist_write_newline): New function to correctly mark
	next records in both external and internal units.
	(nml_write_obj): Use new function.
	(namelist_write: Use new function.

Modified:
    trunk/libgfortran/ChangeLog
    trunk/libgfortran/io/write.c

Comment 6 Jerry DeLisle 2008-08-31 00:09:21 UTC
Subject: Bug 36895

Author: jvdelisle
Date: Sun Aug 31 00:07:58 2008
New Revision: 139814

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=139814
Log:
2008-08-30  Jerry DeLisle  <jvdelisle@gcc.gnu.org>

	PR libfortran/36895
	* gfortran.dg/namelist_53.f90: New test.

Added:
    trunk/gcc/testsuite/gfortran.dg/namelist_53.f90
Modified:
    trunk/gcc/testsuite/ChangeLog

Comment 7 Jerry DeLisle 2008-08-31 00:13:51 UTC
Fixed on 4.4 for scalar character internal unit.