gcc --version gcc (Debian 8.2.0-11) 8.2.0 When preprocessing a file which uses Windows newlines without discarding comments (The -C option) then gcc inserts an extra newline after each line in comments: * Write the following to test.c and make sure it uses Windows newlines /** * Foo- * bar- * quux */ int main() { return 0; } * Execute "gcc -C -E test.c" 3) Expected (this is what clang produces): [...] /** * Foo- * bar- * quux */ int main() { return 0; } * Actual: /** * Foo- * bar- * quux */ # 6 "test.c" int main() { return 0; }
Most likely \r is being treated as a new line just like \n. Remember \r by itself is the new line endings on the classic mac os.
For context, we use gcc in gobject-introspection where we parse metadata from the C comments and this breaks things when users on Windows have git set up to auto convert line endings: https://gitlab.gnome.org/GNOME/gobject-introspection/issues/243
Looking in a hex editor, what gcc is doing is changing the CRLF to LFLF, there is no CR in the output. /* If the file is using old-school Mac line endings (\r only), terminate with another \r, not an \n, so that we do not mistake the \r\n sequence for a single DOS line ending and erroneously issue the "No newline at end of file" diagnostic. */ if (to.len && to.text[to.len - 1] == '\r') to.text[to.len] = '\r'; else to.text[to.len] = '\n'; I noticed this code, but commenting it out makes the compiler fail selftests. I'll keep looking to see if I can find the code responsible for doing that.
All of the non-commments are turned to LF line endings. So it must be something specifically to do with comment processing.
I checked clang's behavior, and it does CRLF -> LF from non-comments, but it leaves them intact in comments. I'm not really sure if this behavior is worth emulating or not. I think it would be better to remove the CR from the CRLF in comments too.