[Bug fortran/78351] comma not terminating READ of formatted input field - ok in 4.1.7, not 4.4.7- maybe related to 25419?

[sgk at troutmask dot apl.washington.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78351

--- Comment #16 from Steve Kargl <sgk at troutmask dot apl.washington.edu> ---
On Wed, Nov 16, 2016 at 06:36:58PM +0000, kevin.b.beard at nasa dot gov wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78351
> 
> --- Comment #13 from Dr. Kevin B. Beard <kevin.b.beard at nasa dot gov> ---
> Hi,
> 
> Thanks for looking at this.  I'm sorry to say I don't have access
>  to the official F77 standards, perhaps you could send me a copy
> of the whole?

google "F77 standard"

https://www.fortran.com/F77_std/rjcnf0001.html
https://gcc.gnu.org/wiki/GFortranStandards

> The section you quoted doesn't seems too exclude the comma-terminated
> behavior I've always seen, and it has been widely used
> by many many programmers throughout the community over the years.


I cited the entire relevant passage.  Now, edited to its essences.

   13.5.9.1 Integer Editing

   The Iw and Iw.m edit descriptors indicate that the field to be
   edited occupies w positions.

   On input, an Iw.m edit descriptor is treated identically to an
   Iw edit descriptor.

   In the input field, the character string must be in the form
   of an optionally signed integer constant, except for the
   interpretation of blanks (13.5.9, item (1)).

In your code, you have

   character*80 s
   s= '1,2,3,,,,'
   READ(s,'(2i10)') i,j

The format request a field width of 10 for 'i'.  So, 10 positions
in 's' are '1,2,3,,,, ' (where I had to add a space because 
technically 's' does not have 10 positions).  A signed integer
constant does not contain 5 commas.

> I've always been told and believed that a comma terminated a
> numeric field;

For list-directed input (i.e., FMT=*), yes, a comma is a 
value separator.

> but w/o > access to the standards I can't point to the line that
> says it must.

You won't find a line.  I cited the entire relevant text from
Fortran 77 that applies to the above code.  You either need to
change the code to

   character*80 s
!      12345678901234567890
   s= '1         2         '
   READ(s,'(2i10)') i,j

where '1' can appear anywhere within the first 10 positions, or

   character*80 s
!      12345678901234567890
   s= '1,2,3,,,,'
   READ(s,*) i,j

> What I'd like to see is that newer gfortran versions support
> its previous (and every other FORTRAN compiler I've tested)
> behavior.

So, no bugs should ever be fixed?  Have you filed bug reports
with all the other vendors?  I suspect that if you use an
option with those vendors' compiler to request Standard
conformance, you'll find that the code is invalid.  If not, 
file a bug report with those vendors.

> The flag "-std=legacy" does not restore the previous behavior,
> and I've found no option in the newer gfortrans that does.

That's because no one has implemented the patch to (un)fix gfortran
to handle invalid code.  jerryd has indicated that he'll look into
the issue.  

I do find it ironic that you refuse to fix broken code,
but expect those that strive to provide a quality tool
like gfortran to break its conformance to the standard.