Re: Escape sequence/parse errors

[Mike Stump <mrs at windriver dot com>]

> From: Zack Weinberg <zack@wolery.cumb.org>
> Date: Wed, 6 Sep 2000 12:06:27 -0700
> To: Michael Vance <briareos@lokigames.com>, gcc@gcc.gnu.org

> On Wed, Sep 06, 2000 at 08:45:51PM +0200, Philipp Thomas wrote:
> > * Michael Vance (briareos@lokigames.com) [20000906 20:33]:
> > 
> > > #line 2 "console\yyparse.c"
> > 
> > > escape.cc:1: unknown escape sequence `\y'
> > > 
> > > Anyway to turn this sort of error off? egcs 1.1.2 compiles without
> > > error.
> > 
> > I'll have to let people like Zack comment on this, but it's obviously
> > misinterpreting the path name.

> This is a dark corner of the standard.  I don't like it much, but:

> #include "dir\name.h"	/* undefined behavior */
> #line 1 "dir\name.h"	/* string contains a newline */

> The string literal of #line is a string-literal, not a header-name, so
> we're required to interpret escapes.  See C99 6.10.4 para 4, compare
> with 6.10.2 para 3; also see 6.4.5 for the definition of a
> string-literal and 6.4.7 for the definition of a header-name.

> You shouldn't use \ in #include either:  "sequences of characters that
> resemble escape sequences cause undefined behavior."

As the author and decider of the current semantics, let me add my
$0.02...

Before I got to it, there were massive inconsistencies and problems.
The solution I choose was to fix all the inconsistencies, make the C
and C++ semantics the same, and that \ in #includes should work to
give as much compatibility to dos and windows.  Also, as noted the
standard says #line is a normal C string, so it should be escape
processed.  I choose to have # 1 "bla bla" match the #include
semantics.  People that want escape semantics could find them via
#line already, and having both, could prove useful to some people.

In your case you can transform #line 1 "..." to # 1 "..." and you'll
be set, or slashify the ....

If someone wants to perform a comprehensive analysis of what other
compilers to, and let us know, we could considering changing some of
the semantics.  I must admit that I choose mainly to make things
consistent, second to that was to try and pick what I thought were the
best semantics possible, though, I admit, I didn't survey tons of
compilers.