[Bug fortran/45108] New: Namelist read: Not aborted when reading from STDIN

[Bug fortran/45108] New: Namelist read: Not aborted when reading from STDIN

[burnus at gcc dot gnu dot org]

gfortran simply continues (with a warning) if one has a wrong namelist in
STDIN.

If one has an IOSTAT variable, it prints the warning but continues with an
IOSTAT == 0.

Using any other means of input (internal unit, external unit) works as
expected, i.e. run-time error - or a non-zero return value for iostat.

Example:

$ gfortran hjff.f90; cat foo.dat|./a.out
Cannot match namelist object name tag3
namelist read: misplaced = sign
 unreachable           0

$ cat foo.dat
&nml tag3=5 /

$ cat hjff.f90
namelist /nml/ tag
character(len=200) str
str ='&nml tg=5 /'
read(*,nml=nml,iostat=ios)
print *, 'unreachable', ios
end

Source code: See line 2964

http://gcc.gnu.org/git/?p=gcc.git;a=blob;f=libgfortran/io/list_read.c;hb=HEAD#l2964


-- 
           Summary: Namelist read: Not aborted when reading from STDIN
           Product: gcc
           Version: 4.6.0
            Status: UNCONFIRMED
          Keywords: wrong-code
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: burnus at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45108

[Bug fortran/45108] Namelist read: Not aborted when reading from STDIN

[burnus at gcc dot gnu dot org]

------- Comment #1 from burnus at gcc dot gnu dot org  2010-07-28 15:01 -------
That seemingly goes back to implementing support for:

+/* If the namelist read is from stdin, output the current state of the
+   namelist to stdout.  This is used to implement the non-standard query
+   features, ? and =?. If c == '=' the full namelist is printed. Otherwise
+   the names alone are printed.  */

Cf. commit:
http://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=fc2a7c2711d61197795e86f34a978af6f71d8a34


Still, the status quo is not the correct solution - and highly irritating if
one works with long input and pipes.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45108

[Bug fortran/45108] Namelist read: Not aborted when reading from STDIN

[burnus at gcc dot gnu dot org]

------- Comment #2 from burnus at gcc dot gnu dot org  2010-07-28 15:07 -------
See also: http://gcc.gnu.org/onlinedocs/gfortran/Extensions-to-namelist.html

I understand the support of ? and =?, but why can't one give a proper error is
one returns? If one starts a dialog with ? / =?, one stays in the I/O, but if
one returns, a proper error should be used - at least if one has never started
a ? / =? conversation.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45108

[Bug fortran/45108] Namelist read: Not aborted when reading from STDIN

[jvdelisle at gcc dot gnu dot org]

------- Comment #3 from jvdelisle at gcc dot gnu dot org  2010-07-29 00:59 -------
I will have a look.


-- 

jvdelisle at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |jvdelisle at gcc dot gnu dot
                   |dot org                     |org
             Status|UNCONFIRMED                 |ASSIGNED
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2010-07-29 00:59:45
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45108

[Bug fortran/45108] Namelist read: Not aborted when reading from STDIN

[jvdelisle at gcc dot gnu dot org]

------- Comment #4 from jvdelisle at gcc dot gnu dot org  2010-08-17 03:18 -------
There was some history regarding legacy codes as the reason why this does not
error out. ie looping back and trying again was a feature.  I think I may put
this behind -std=legacy.  It does seem odd the way we are doing this now.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45108

[Bug fortran/45108] Namelist read: Not aborted when reading from STDIN

[burnus at gcc dot gnu dot org]

------- Comment #5 from burnus at gcc dot gnu dot org  2010-08-17 07:54 -------
(In reply to comment #4)
> There was some history regarding legacy codes as the reason why this does not
> error out. ie looping back and trying again was a feature.  I think I may put
> this behind -std=legacy.  It does seem odd the way we are doing this now.

Can you give an example how to use this? For "?", "=", and "=?" this does not
seem to be needed as one does not return to the program. And while I see a
reason for staying in the dialog when an error occurs (i.e. to enter a correct
namelist), immediately returning to the program without setting iostat/=0 or
jumping to the err= label seems odd to me. -- I tried hard but I still fail to
come up with any usage scenario where it makes sense. Unless we find a (even
remotely) useful usage scenario, I would not even enable it with -std=legacy.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45108

[Bug fortran/45108] Namelist read: Not aborted when reading from STDIN

[jvdelisle at gcc dot gnu dot org]

------- Comment #6 from jvdelisle at gcc dot gnu dot org  2010-08-19 03:52 -------
Created an attachment (id=21516)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21516&action=view)
Proposed patch

This patch will generate an error.  If IOSTAT or IOMSG is used, the read will
continue in the loop after an error, but the error status variables will be set
so that one will know an error occurred when the READ has completed.  Any
thoughts Tobias?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45108

[Bug fortran/45108] Namelist read: Not aborted when reading from STDIN

[burnus at gcc dot gnu dot org]

------- Comment #7 from burnus at gcc dot gnu dot org  2010-08-19 09:04 -------
(In reply to comment #6)
> This patch will generate an error.  If IOSTAT or IOMSG is used, the read will
> continue in the loop after an error, but the error status variables will be set
> so that one will know an error occurred when the READ has completed.  Any
> thoughts Tobias?

I think that's useful. One can use the interactive dialog to query about the
correct format (as before), if one enters the correct nml one returns without
error (as before), but if one enters an invalid namelist one returns (as
before) but with an error status (new) and without an warning ("namelist read:
misplaced = sign") [new]. (One can use iomsg to get the error string.) And
without err=/iostat=, one gets a run-time error as before.

[Admittedly, I have never used the ? / =? feature thus I might overlook a
useful application which won't work with the new patch, but it seems as if most
things continue to work.]

Thus, I think the patch is fine. As it is not test-suite testable, no test case
is needed. From my side the patch is OK for committal.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45108

[Bug fortran/45108] Namelist read: Not aborted when reading from STDIN

[jvdelisle at gcc dot gnu dot org]

------- Comment #8 from jvdelisle at gcc dot gnu dot org  2010-08-19 20:28 -------
Subject: Bug 45108

Author: jvdelisle
Date: Thu Aug 19 20:28:09 2010
New Revision: 163387

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

        PR libfortran/45108
        * io/list_read.c (namelist_read): If namelist reading fails, use
        generate_error and then continue the read loop.

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


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45108

[Bug fortran/45108] Namelist read: Not aborted when reading from STDIN

[jvdelisle at gcc dot gnu dot org]

------- Comment #9 from jvdelisle at gcc dot gnu dot org  2010-08-19 20:32 -------
Closing


-- 

jvdelisle at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45108