[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Tinycc-devel] Parsing bug
From: |
Rob Landley |
Subject: |
Re: [Tinycc-devel] Parsing bug |
Date: |
Mon, 14 May 2007 14:09:07 -0400 |
User-agent: |
KMail/1.9.1 |
On Monday 14 May 2007 4:40 am, Dave Dodge wrote:
> On Mon, May 14, 2007 at 01:48:58AM -0400, Rob Landley wrote:
> > 1) The #include <gl\glaux.h> doesn't get parsed on Linux systems because
the
> > #ifdef prevents everything until the #else from being looked at.
>
> Not so sure about that. Compiling this:
>
> #if 0
> #include <a:\qqq>
> #endif
>
> fails with "stray '\' in program". From a quick glance at
> preprocess_skip() where it calls handle_stray(), there's a comment
> suggesting that this may be a known bug.
>
> My guess is that it's treating all backslashes between the #if/#endif
> pair as part of escape sequences, instead of handling C's special case
> tokenization of header names. I don't see any obvious code in there
> checking for an #include context, for example.
#if 0
blah \
#endif
#endif
It has to pay attention to at least _that_ backslash, I'd think. (Crazy
special case that that is.)
I note that Windows code has workarounds (use / which DOS and its derivatives
have accepted as a directory separator since DOS 2.0 which _introduced_
subdirectories). However, in #include context I suspect the only \ it should
care about is at the end of lines...
Rob