http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44191
Israel Pinkas <ipinkas at nds dot com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |ipinkas at nds dot com --- Comment #2 from Israel Pinkas <ipinkas at nds dot com> 2012-09-11 22:40:08 UTC --- A am not sure what Jakub means by Locus, but the C and C++ standards are clear that during the preprocessing stage, the sequence backslash-newline is dropped from the stream. Line splicing occurs before tokenization. While in most situations there is no difference, there are some cases which are affected by this bug: 1. Token splicing. Two tokens are separated by only a backslash-newline in the source are supposed to be concatenated into a single token. In a bizzare twist to this bug, this behavior is preserved. See example below. 2. Use of cpp for other purposes. There exist multiple software packages which are not compilers for C-line languages that use cpp as a preprocessor, accepting that cpp is C-oriented in a number of ways. This includes some assemblers and other packages that need file inclusion, conditional compilation, and simple macros. Many of these packages rely on the line splicing. The bug description needs to be slighly ammended. The splicing behavior was changed only when the first character following the newline is a space or tab. The following demonstrates: ==== x.txt ==== Test\ ing Test\ case ==== END ==== $ cpp x.txt # 1 "x.txt" # 1 "<built-in>" # 1 "<command-line>" # 1 "x.txt" Testing Test code ========== The first instance spliced the tokens. However, the second instance left the newline, a change in behavior and a deviation from the spec.