http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57714
--- Comment #17 from David Krauss ---
Yes, my preprocessor classifies the backslash-after-preprocessing as a
whitespace token. I simply don't intend to make textual preprocessing output.
With raw strings, UCNs, and user-defined literals, there's j
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57714
--- Comment #16 from Harald van Dijk ---
(In reply to David Krauss from comment #14)
> 1. Actually the C standard does care whether whitespace is added.
You're right for stringizing, but GCC already takes care to treat that as a
special case.
#d
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57714
--- Comment #15 from David Krauss ---
Corrections to previous: Harald's comment is #11, and I meant to refer to the
commits in my repo from
http://code.google.com/p/c-plus/source/detail?r=d462b650c355b606545158f4da7365180b699752
up through
http://
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57714
--- Comment #14 from David Krauss ---
Harald's comment #10 is almost accurate, but for two things:
1. Actually the C standard does care whether whitespace is added. Whitespace is
visible in the result of stringizing, and when comparing duplicate
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57714
--- Comment #13 from Harald van Dijk ---
Sure. I have no strong preference on the matter, and have changed the wiki.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57714
--- Comment #12 from Manuel López-Ibáñez ---
(In reply to Harald van Dijk from comment #11)
> Could you either not suggest that the current behaviour is a bug (even if it
> is a minor one) in the FAQ, or change the documentation so that it is
> un
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57714
Harald van Dijk changed:
What|Removed |Added
CC||harald at gigawatt dot nl
--- Comment #
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57714
--- Comment #10 from David Krauss ---
I don't plan on fixing this in GCC, but I did implement the feature today in my
own preprocessor, http://code.google.com/p/c-plus/source/list . It does require
a handshake between phases 2 and 3, because a tok
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57714
--- Comment #9 from Manuel López-Ibáñez ---
I think what happens is that the preprocessor is trying to avoid breaking up a
valid token like in:
void foo(void) {re\
turn;
}
It would be an improvement if it ignored the \ between valid tokens bound
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57714
--- Comment #8 from David Krauss ---
Probably what happened:
1. In preserving visual appearance, tokens not separated by spaces are kept
together.
2. Line splicing happens before spaces are identified for the above.
3. The { and return tokens are
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57714
--- Comment #7 from David Krauss ---
Oh, OK, now I followed that link. Splicing is supposed to be transparent unless
you specify -P. This still qualifies as a bug.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57714
--- Comment #6 from David Krauss ---
Just to clarify the last comments, the input
main(){\
return 0;
}
translates via cpp to
main(){
return 0;
}
i.e. no splicing is apparent in the output.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57714
--- Comment #5 from David Krauss ---
What? That makes even less sense. Are you guys familiar with the concept of
line splicing? See "phases of translation" in the Standard, namely phase 2.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57714
Manuel López-Ibáñez changed:
What|Removed |Added
CC||manu at gcc dot gnu.org
--- Comment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57714
--- Comment #3 from David Krauss ---
See section 9 of the manual:
http://gcc.gnu.org/onlinedocs/gcc-4.8.1/cpp/Preprocessor-Output.html#Preprocessor-Output
The output from the C preprocessor looks much like the input, except that all
preprocessing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57714
--- Comment #2 from David Krauss ---
Andrew, are you sure? The zero should remain on the same line as the "return"
token.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57714
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
17 matches
Mail list logo
