This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
Re: cpp mishandles \ in filenames
- From: Zack Weinberg <zack at codesourcery dot com>
- To: mike stump <mrs at windriver dot com>
- Cc: gcc-bugs at gcc dot gnu dot org
- Date: Thu, 10 Jan 2002 22:04:12 -0800
- Subject: Re: cpp mishandles \ in filenames
- References: <200201110311.TAA26143@kankakee.wrs.com>
On Thu, Jan 10, 2002 at 07:11:53PM -0800, mike stump wrote:
> > I do not see what else you could mean by "mishandles \ in filenames."
>
> Ah, I get it, someone changed the the various semantics of #, and
> quoting and what not,
Hmm, now you've made me go look at this, and we may have a standard
compliance issue here. #line takes a true string-literal, not
" q-char-sequence " the way #include does. That may mean that escapes
are supposed to be interpreted. The original change was intended to
make #line and #include consistent, but we may not be allowed to do
that.
Possibly we shouldn't try to treat the #-markers so much like #line,
either.
> $ echo 'int i;' > 't
> "f.c'
> $ gcc -E 't
> "f.c'
> # 1 "t
> "f.c"
> int i;
> $ gcc -c 't
> "f.c'
> /usr/ccs/bin/as: "/var/tmp//ccZCsycb.s", line 1: error: unterminated string
> /usr/ccs/bin/as: "/var/tmp//ccZCsycb.s", line 2: error: unterminated string
> /usr/ccs/bin/as: "/var/tmp//ccZCsycb.s", line 2: error: statement syntax
Okay, fine, we have bugs here. In particular
$ cat x.s
.file "t
\"f.c"
.comm i,4,4
.ident "GCC: (GNU) 3.1 20020110 (experimental)"
*that* string is supposed to be escaped, because as most certainly
does read it back in with escape interpretation. Looks like
output_quoted_string assumes bare newlines are okay. Argh.
zw