Patch proposal for PR 19678

[Tobias Schlüter]

François-Xavier Coudert wrote:
>>Doesn't this patch mean that DOS line breaks ('\n\r') will be interpreted as
>>two separators?
> 
> 
> No, since DOS line breaks are "\r\n". All matching that was done with '\n' 
> is now done with '\n' or '\r', while all "eating" still only looks for '\n'. 
> In current form, it works only because DOS line breaks are "\r\n" and not 
> "\n\r".

Hm, I didn't know that.  I did a search around the web and it seems to be the
case that  \n\r only appears in weird places (like Linux' old terminal
drivers), so this is probably fine.  I'm still worried that there might be
places where two consecutive linebreaks have a different meaning than a single
line break, though.  Also, do our output routines on windows write '\r\n' or '\n'?

> What about:
> 
> 2005-02-24  François-Xavier Coudert  <coudert@clipper.ens.fr>
> 
> 	PR libfortran/19678
> 	* list_read.c: Add support for DOS files, adding '\r' in the list of 
> possible separators (is_separator and CASE_SEPARATORS). Many tests for "c == 
> '\n'" changed to "(c == '\n' || c == '\r')" (in next_char, eat_separator, 
> finish_separator, read_real and namelist_read).
> 

Please stick to the conventional layout which would look something like:
2005-02-24  François-Xavier Coudert  <coudert@clipper.ens.fr>

	PR libfortran/16978
	* list_read.c (CASE_SEPARATORS, is_separator): Add '\r'.
	(next_char, eat_separator, finish_separator, read_real,
	namelist_read): Also check for '\r' as record separator (newline
	character).

(I'm not sure this is right, because your diff doesn't show which functions
the different hunks belong to, this is what -p does)

- Tobi