[Bug preprocessor/8270] [4.7/4.8/4.9 Regression] back-slash white space newline with comments, no warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8270 --- Comment #51 from GoWhoopee at yahoo dot com --- http://web.cs.dal.ca/~vlado/pl/C_Standard_2011-n1570.pdf That's the principle, but not what happens with gcc... Phase 2 says, Each instance of a backslash character (\) immediately followed by a newline character is deleted, splicing physical source lines to form logical source lines., and explicitly states that, Only the last backslash on any physical source line shall be eligible for such a splice.. I wonder if all trailing white-space is being trimmed from each source line before or during the first Translation Phase?
[Bug preprocessor/8270] [4.7/4.8/4.9 Regression] back-slash white space newline with comments, no warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8270
--- Comment #52 from GoWhoopee at yahoo dot com ---
Whitespace is required by Translation Phase 3, consequently Translation Phase 1
should not be changing whitespace at all, only mapping multibyte characters and
trigraphs.
Comment #39: Indicates that gcc is known to work incorrectly, This (removal of
such spaces) is part of how GCC defines the implementation-defined mapping in
translation phase 1.: the removal of white-space is not mapping multibyte
characters or trigraphs, it is removing critical information from Translation
Phases 2 and 3 resulting in misinterpretation of the source code.
Looking at the 4.8.2 source, libcpp\lex.c line 1427, there is a fix when
parsing raw strings, after the event:
__
static void
lex_raw_string (cpp_reader *pfile, cpp_token *token, const uchar *base,
const uchar *cur)
{
[...]
switch (note-type)
{
case '\\':
case ' ':
/* Restore backslash followed by newline. */
BUF_APPEND (base, cur - base);
base = cur;
BUF_APPEND (\\, 1);
after_backslash:
if (note-type == ' ')
{
/* GNU backslash whitespace newline extension. FIXME
could be any sequence of non-vertical space. When we
can properly restore any such sequence, we should mark
this note as handled so _cpp_process_line_notes
doesn't warn. */
BUF_APPEND ( , 1);
}
BUF_APPEND (\n, 1);
break;
__
but fixing all the varieties of broken things after the event wouldn't be
necessary if Translation Phase 1 didn't trim whitespace.
If Translation Phase 1 is required to trim whitespace for some reason
(performance, perhaps) then it should trim multiple consecutive spaces down to
exactly one space; which wouldn't break Translation Phase 2 and 3.
Does that sound like a sensible compromise?
[Bug preprocessor/8270] [4.7/4.8/4.9 Regression] back-slash white space newline with comments, no warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8270 --- Comment #49 from GoWhoopee at yahoo dot com --- I've read all the comments and all those on linked forums and I have no idea how you struggle with this! If a compiler changes backslash space into backslash newline and consequently deletes the newline it is changing the meaning of the code! All other development environments people here have used don't do this and gcc shouldn't! Here's an example of code your compiler changes: #define HIGH_SPEED_TURRET // \ #define SAFETY_LOCKED_ON// - Critical Configuration #define NEVER_PRIME_MISSILE // / The programmer put backslash space and the syntax highlighter correctly showed the safety was locked on. Sleep well.
[Bug preprocessor/8270] [4.7/4.8/4.9 Regression] back-slash white space newline with comments, no warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8270 GoWhoopee at yahoo dot com changed: What|Removed |Added CC||GoWhoopee at yahoo dot com --- Comment #47 from GoWhoopee at yahoo dot com --- There is a rule: single line comments are extended by backslash newline. Ludicrous as it is, this rule is not optional. Failure to observe this rule by a compiler is criminal: the result is that lines of code which a correctly written syntax highlighter shows as code that will be compiled, are not. This has cost this company several days in time. We write code for the military: the cost could have been far worse had the unusual behaviour not been noticed. Compilers MUST NOT randomly ignore lines of code! Programmers frequently illustrate code with ASCII art and backslash is a valuable ASCII art character. To ensure the single-line comment is not extended and the clarity of the ASCII art remains, a space would be inserted after any trailing backslash. ASCII art (or anything attempt at explanation of the code) in comment is NOT bad coding style (as stated by Atmel technical support). Any editor or compiler operation that trims spaces from lines MUST NOT trim spaces all the way back to a backslash because that will change the programmers intent by creating backslash newline where there was none! That should be obvious! GCC isn't alone in missing this crucial point. Atmel's version of MS Visual Studio offers a [Tools][Options][Environment][Custom Settings][Remove whitespaces trailing end of line, while saving the document] which does what it says, silently breaking code as it does so. Their tech support said their environment did what it said on the tin and they couldn't impose themselves on the GCC community, but they could write to the syntax highlight software company and ask them to break their code too! Oh, how we laughed... The solution should be simple: when trimming white-space from the right of a line of code, don't create backslash newline where it didn't exist before. Please reconsider and stop gcc from changing our code without our permission.
