This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

backslash-newline, trigraphs, and the C standard



I'm opposed to the \-newline change you suggest.  \-newline 
is a simple, well understood, and often used feature of the
C and C++ languages.  I don't think we should be changing
it to deal with trigraph issues.  I don't think the compiler
speed up argument justifies this change either; there
are lot of better ways to improve the speed of the compiler.
Lets try and find a better way to solve the trigraph warning
problems.

I'd like to understand the problem better.  It seems at
first blush, that one or more Linux developers forgot, or
didn't know that trigraphs apply everywhere in the source,
even in comments.  Trigraphs work this way to make it easy
to translate files to and from trigraph versions.

While it would be possible to add option(s) to change
the handling of trigraphs in comments, I would really
rather avoid adding an unnecessary option.  Would the
Linux developers be willing to turn off trigraph warnings?
Would they be willing (and is it possible) to change
the Linux source so these warnings don't exibit?  I 
want to support the Linux project, but I don't want
add unnecessary stuff to GCC.

                                   -gavin...

[As an aside; yes, the 

 > #def\
 > ine \
 > pooh\
 > bah blurf

behavior you point out is generally unused, and often not
understood, it is very useful for importing code to file
systems that have arbitrary line length restrictions.
This isn't a particularly good argument for or against 
your \-newline proposal; I just wanted to point out that
this behavior, is actually useful at times.  ]


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]