http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59727
--- Comment #5 from Marian Szebenyi <dms35 at cornell dot edu> --- (In reply to Jerry DeLisle from comment #4) Seems to me that once the 4 items requested in the read statement have been satisfied, i.e. 4 properly-delimited items have been found, what is in the rest of the string should be irrelevant. With this interpretation, the original code is perfectly valid. > The following also runs without error. > > My initial thought is that the content of the string after the 20th char is > undefined and this results in undefined behavior. As Steve notes, any junk > can be in there. > > C TEST READING FROM CHARACTER STRING > CHARACTER*144 LINE > C > LINE(1:20)=' 12,30.0,10.5,0 ' > C CRASHES AT RUN-TIME UNLESS THE FOLLOWING LINE IS UNCOMMENTED > C LINE(30:30)=CHAR(10) > READ (LINE(1:20),*) I1,R1,R2,I2 > WRITE (*,1000) I1,R1,R2,I2 > 1000 FORMAT (I4,2F10.2,I4) > END > > I think the original code is invalid because of the undefined string. Prior > to the patch mentioned in Comment 1, the run-time library did not "read" or > interpret an EOF character. > > Tracing the error shows that the error occurs in finish_list_read where we > do an eat_line which gives the error. If we want to accept the behavior, we > probably could have a unique eat_line for internal character units. > > I am not sure we want to accept the behavior yet and I don't think we should > call it a regression.
