NAMELIST input and &

[John4]

Hi,

Although the following code seems valid:

implicit none

logical :: l = .FALSE.
integer :: i = -1
real :: r = 0.
character(5) :: c = ''

namelist /input/l, i, r, c

open (UNIT = 101, FILE = 'input.dat', STATUS = 'OLD')
    read (101, input)
close (101)

write (*,input)
end

There should be a warning or error of some sort when reading a namelist with a non-standard termination, like for example:

&input
l = T, &
i = 1,
r = 2.,
c = '12345'
/

The warning is especially useful if the -stand option is given during compliation.  Here's what compiling with gfortran shows, followed by ifort's equivalent:

...:~$ ll `which gfortran`
lrwxrwxrwx 1 root root 12 May  3 12:57 /usr/bin/gfortran -> gfortran-4.8*
...:~$ ll `which ifort`
-rwxr-xr-x 1 root root 4013312 Apr 25 08:19 /opt/intel/composer_xe_2013_sp1.3.174/bin/intel64/ifort*
...:~$ gfortran test_namelist.f90 
...:~$ ./a.out 
At line 11 of file test_namelist.f90 (unit = 101, file = 'input.dat')
Fortran runtime error: namelist not terminated with / or &end
...:~$ ifort -stand test_namelist.f90 
...:~$ ./a.out 
 &INPUT
 L       = T,
 I       =          -1,
 R       =  0.0000000E+00,
 C       =      
 /

As of today, I know ending the namelist with & is an extension, but since I shouldn't have to be aware of every single extension in ifort (or gfortran), I just spent two days trying to find a non-existent bug in the code.

[Steven_L_Intel1]

You're referring to the & on the second input line? It's not an extension and we don't deliberately treat that as ending the namelist. This may simply be a bug. Please note, though, that we do standards checking of compile-time syntax only. We don't try to give warnings for "non-standard" things at run-time. I am puzzled that gfortran considers that & an end of the namelist input rather than an error, which is what I think it should be. I will discuss this with the developers.

[John4]

The compiler's documentation (Namelist input section) has the following example:

!  The following are all valid namelist variable assignments:
         &mynml a = 1 /
         $mynml a = 1 $
         $mynml a = 1 $end
         &mynml a = 1 &
         &mynml a = 1 $END
         &mynml
         a = 1
         b = 2
         /

Which might lead people like me to believe that using "&" to terminate a namelist is an extension.

Gfortran has its own set of extensions as well, and it accepts "$name... $end" and "&name... &end", so maybe that's why it complained about the "&" missing the "end"

[Steven_L_Intel1]

$name and $end are the old IBM way of doing NAMELIST, and a lot of compilers, including ours, support that. F90 chose a form that nobody implemented already, so compilers had to support both.

I don't see that we document & as a group terminator, except in the example. At this point I doubt we'll make it an error, though I have to wonder how it snuck in there. If we're going to support it as an extension, we should document it as such. (We do say that undelimited character values are terminated by a & but that's another thing entirely.)

Nevertheless, we don't do any run-time diagnostics for non-standard input.

[John4]

Yes, I've noticed that the -check options related to I/O are only for output... But one -check option for non-standard input or input with (possibly) unintended conversion would have been nice.