Re: possible bug in fortran compiler

[Craig Burley <burley at gnu dot org>]

>The Standard says:
>
>10.8.1 List-directed input
>
>...
>When the next effective item [ of the list of variables on the read  
>statement ] is of type integer, the value in the input record is  
>interpreted as if an Iw edit descriptor with a suitable value of w [  
>width in characters ] were used.

I think 10.8 itself supercedes this somewhat, with its notion
of values and value separators.  So, while it's certainly true
that "1.2" is invalid input for an INTEGER in a list-directed
input, it doesn't seem as though the standard is saying that
the input for that item ends between the "1" and the "." --
becauuse "." is not a value separator.

What I can't quite figure out from the draft copy of the standard
I have (though presumably it's addressed in the huge pile of
colored interpretation/edit sheets I have yet to go through) is
just what behavior *is* mandated for such a case.  If it's simply
undefined, then we're fine with dmg's changes to netlib's libf2c
(which egcs now includes).  If it's defined as an error condition
that should therefore DTRT with regard to IOSTAT= and ERR=, then
perhaps we should let dmg know the patch might not be correct,
but maybe the original code wasn't, either.

In particular, I can't quite find where the standard says (if it
does say) that "1.2" as input to an INTEGER item (whether
formatted Iw or list-directed) raises what the standard calls "an
error condition", which pertains to IOSTAT=, ERR=, and all that.

The wording I do find is the usual use of "must" that indicates
to me that "1.2" represents an undefined input, meaning the
system can start WW3, or just define the corresponding integer
with the converted-to-integer value and proceed, or whatever.

In summary, unless someone can identify for me the place where
the standard says `READ *, I', where the input is "1.2", is an
*error* condition, I think we're okay with the change dmg made,
as we were with the way things worked before his change.  That is,
it seems to be a quality-of-implementation issue to me.

        tq vm, (burley)