This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Patch proposal for PR 19678

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  <>
> 	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  <>

	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

(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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]