! 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

Reply via email to