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

[jvdelisle at charter dot net]

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

--- Comment #4 from jvdelisle at charter dot net ---
On 11/14/2016 11:09 AM, kargl at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78351
>
> kargl at gcc dot gnu.org changed:
>
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>                  CC|                            |kargl at gcc dot gnu.org
>
> --- Comment #3 from kargl at gcc dot gnu.org ---
> (In reply to Dr. Kevin B. Beard from comment #0)
>> Created attachment 40038 [details]
>> Simple example - comma no longer  a format field delimiter - gfortran 4.1.2
>> ok, 4.4.7- fails
>>
>> Here @ NASA we often have strings to read of the form:
>>
>> #,#,#,#,.....
>>
>> and on many platforms, gfortran 4.1.2 and (most?) earlier, Intel Fortran
>> 16.0.3, g77-3.4.6 and most other FORTRANs, it would treat the "," as a field
>> delimiter during a formatted READ - for example (x1.f):
>>
>>       character*80 s
>>       s= '1,2,3,,,,'
>>       READ(s,'(2i10)') i,j
>>       write(6,'(2i10)') i,j
>>       end
>>
>> would print "       1         2".
>>
>> However, 4.4.7 ("gfortran -o x1 x1.f") now (11/2016) fails with
>>
>> "Fortran runtime error: Bad value during integer read".
>>
>> I believe it worked with 4.4.7 back in 9/2016 on ScientificLinux-6.4 fine,
>> but there have been security patches done since then.  It also fails on
>> 4.8.5 and 5.3.0 under Red Hat Enterprise Linux Server release 5.11  It would
>> be very nice to be able to restore the old behavior.
>>
>> This may be related to bug#25519.
>
> gfortran's behavior conforms to the standard while your code
> does not conform.  Perhaps, gfortran should accept a comma as
> a field delimiter under -std=legacy, but preference should
> be to fixing the wrong code.
>
>   10.7.2.2 Integer editing
>
>   The Iw and Iw.m edit descriptors indicate that the field to be
>   edited occupies w positions, except when w is zero.  When w is
>   zero, the processor selects the field width.  On input, w shall
>   not be zero.  The specified input/output list item shall be of
>   type integer. ...
>
>   On input, m has no effect.
>
>   In the input field for the I edit descriptor, the character string
>   shall be a signed-digit-string (R409), except for the interpretation
>   of blanks.
>
>   R409 signed-digit-string  is [ sign ] digit-string
>   R410 digit-string
>   R411 sign                 is digit [ digit ] ...
>
>                             is +
>                             or ­
>
>
> Perhaps, you want list-directed formatting
>
>   10.10 List-directed formatting
>
>   10.10.1 General
>
>   List-directed input/output allows data editing according to the type
>   of the list item instead of by a format specification.  It also allows
>   data to be free-field, that is, separated by commas (or semicolons) or
>   blanks.
>

Thank you for that clarification. That makes it not a regression really, just
an 
enhancement.

Jerry