https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91733
Bug ID: 91733
Summary: No longer treat carriage return as an end-of-line
Product: gcc
Version: 9.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: akim.demaille at gmail dot com
Target Milestone: ---
Hi!
Long long ago, MacOS Classic used '\r' as end-of-line, and since then GCC
accepts \n, \r, and \r\n as means to denote end-of-line.
Today's tools that show line numbers (e.g., Emacs in default modes, sed, cat,
wc, etc.) treat lone \r as a regular (blank) character, _not_ as an
end-of-line. This introduces a discrepancy between GCC and the other tools.
Worse yet: it seems that GCC's scanner and its diagnostics module disagree on
what an EOL is: see (i) what diagnostics think line 2 is (it contains the "i;"
part), and (2) what line is actually quoted in line 3 (compare the first and
last diagnostics).
$ cat -An /tmp/foo.c
1 int;$
2 intt ^Mi;$
3 int ;$
4 /* foo */$
$ gcc-mp-9 /tmp/foo.c
/tmp/foo.c:1:1: warning: useless type name in empty declaration
1 | int;
| ^~~
/tmp/foo.c:2:1: error: unknown type name 'intt'; did you mean 'int'?
2 | intt i;
| ^~~~
| int
/tmp/foo.c:4:1: warning: useless type name in empty declaration
4 | /* foo */
| ^~~
GCC should probably stop treating lone carriage-returns as end-of-line in its
scanners.
FWIW, Bison suffered from exactly the same problems, and we (Paul Eggert and I)
decided to stop treating \r as an EOL
(https://lists.gnu.org/archive/html/bison-patches/2019-09/msg00027.html,
https://lists.gnu.org/archive/html/bison-patches/2019-09/msg00028.html).
Cheers!
