[Bug fortran/45710] New: WRITE of NAMELIST group to internal file contains newline characters
urbanjost at comcast dot net
gcc-bugzilla@gcc.gnu.org
Fri Sep 17 21:03:00 GMT 2010
! In gfortran a WRITE of a NAMELIST group into an internal file appears to all
! go into the first record. The standard doesn't seem to specify what will
happen,
! and of three compilers that I tested that supported this F2003+ each did it
! differently. My only major complaint with that is that I first guessed that
your output
! into an internal file would be formatted just like it was to stdout.
!
! But gfortran output to stdout or to a file writes in a very different format,
! putting one keyword=value per line (which I like, but is also not required by
! any standard requirement I can find).
!
! But if you write out the internal file the output can deceptively appear to
be the
! same, as the first element has newline
! characters between each field; so it appears that the NAMELIST output to an
internal
! file has used multiple records.
!
! I think the standard DOES prohibit the use of newline characters in the
output string.
!
! It took me a while to realize what was going on when adding a few new
variables
! to my NAMELIST started causing errors even though I had more than enough
records in my
! character array to hold the NAMELIST variables if the output was one variable
per record.
!
! So at a minimum even if this is not changed the gfortran documentation should
describe
! how it writes a NAMELIST to an internal file, or I am sure anyone trying this
will be
! confused.
! If it is changed, it would seem sensible that the output to the internal file
would take
! just as many records as the write to a file or stdout takes.
!
! I did not try this on an MSWindow platform, so I do not know if the newline
is then a
! carriage-return + a newline or still just a newline, but this would be
portability issue
! even if the only compiler you are using is gfortran.
!
! Also, note that a large NAMELIST group would require a very large character
variable length.
!
! 20100917 - JSU
PROGRAM NMIF
! when writing a NAMELIST group to an internal file the entire NAMELIST
! output is written to a single character variable, and no wrapping is
! provided even if the internal file is an array.
! note that because arbitrary whitespace is allowed in NAMELIST output,
! and variable precision can easily change via compiler switches, let
! alone platform, that it would be nice if there were some way to query
! the required length, or change the output variable to fit.
! with F2003 if the variable used as an internal file is allocatable
! will it be resized to fit the output generated?
INTEGER ::
A=1,B=2,C=3,D=4,E=5,F=6,G=7,H=8,I=9,J=10,K=11,L=12,M=13,N=14,O=15,P=16
NAMELIST /NL1/ A,B,C,D,E,F,G,H,I,J,K,L,M,N,O,P
PARAMETER(ILINES=3)
CHARACTER(LEN=264) :: OUT(ILINES)
DO I20=1,ILINES
DO I10=1,LEN(OUT)
OUT(I20)(I10:I10)='@'
WRITE(OUT(I20)(1:4),'(I3.3,1X)')I20
ENDDO
ENDDO
write(*,*)'STDOUT:'; WRITE(6,NL1) ! one variable per line
write(*,*)'DISK:'; WRITE(10,NL1) ! one variable per line
write(*,*)'INTERNAL FILE:'; WRITE(OUT(2:),NL1); WRITE(*,'(A)')OUT ! all in one
record??
WRITE(*,*)'DUMP LINE:'; CALL PDEC(OUT(1:1))
END PROGRAM NMIF
! @(#) write string with ASCII Decimal Equivalent (ADE) numbers vertically
under it
subroutine pdec(string)
implicit none
character(len=*) :: string
integer ilen
integer i
ilen=len_trim(string(:len(string)))
! replace lower unprintable characters with spaces
write(*,101)(char(max(32,ichar(string(i:i)))),i=1,ilen)
! print ADE value of character underneath it
write(*,202)(ichar(string(i:i))/100,i=1,ilen)
write(*,202)(mod(ichar(string(i:i)),100)/10,i=1,ilen)
write(*,202)(mod((ichar(string(i:i))),10),i=1,ilen)
101 format(9999a1:)
202 format(9999i1:)
return
end subroutine pdec
--
Summary: WRITE of NAMELIST group to internal file contains
newline characters
Product: gcc
Version: 4.3.4
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: urbanjost at comcast dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45710
More information about the Gcc-bugs
mailing list