Re: implementing #include etc without pre-preprocessing

"Scott Stanchfield" <>
18 Mar 1997 13:01:33 -0500

          From comp.compilers

Related articles
implementing #include etc without pre-preprocessing (Sudhakar Frederick) (1997-03-16)
Re: implementing #include etc without pre-preprocessing (Scott Stanchfield) (1997-03-18)
Re: implementing #include etc without pre-preprocessing (1997-03-21)
Re: implementing #include etc without pre-preprocessing (1997-03-21)
Re: implementing #include etc without pre-preprocessing (1997-03-21)
Re: implementing #include etc without pre-preprocessing (1997-03-22)
| List of all articles for this month |

From: "Scott Stanchfield" <>
Newsgroups: comp.compilers
Date: 18 Mar 1997 13:01:33 -0500
Organization: scruz-net
References: 97-03-090
Keywords: lex, parse, C

As our moderator says, it can be done. The trick is to have a scanner that
performs extra processing on #if et al and only passes tokens to the parser
that are in the source text that pass the tests.

John mentions a parser for the expressions -- you really need a separate,
nested parser invocation called from the scanner for this. Otherwise your
grammar would need to have rules for #if everywhere...

One (easy) way to do this is with a recursive-descent parser, such as one
generated by PCCTS. Suppose your grammar had a start rule called
translationUnit and had a high-level expression rule called expression.
You create an extra start rule called startExpression that just matches
expression followed by EOF.

You would start your main parse by calling translationUnit, using a parser
that grabs tokens from a scanner that reads a text file.

When the scanner sees #if, it gobbles the rest of the line, and invokes
startExpression on it, using a scanner that reads the stored string instead
of a file. (Use a different instance of the same scanner, but make it read
from a string instead of a file.)

So you get the first scanner invoking the second scanner to parse the
expression, then set a flag based on the value of the expression, and have
that flag determine whether tokens are returned to the parser or sent to
the bit bucket.

-- Scott

Scott Stanchfield, Santa Cruz CA
See my PCCTS Tutorial at

Sudhakar Frederick <> wrote

> Is it practical to implement "conditional compilation" C-style
> constructs similar to #include, #define #ifdef etc. as part of the
> parsing rather than through a pre-processor. I'm using Bison and Flex.
> [Look at the flex manpage, wherein is found great wisdom on creating,
> deleting, and switching among input buffers. Yes, you can do this
> although the expressions in #if require a complete expression parser. -John]


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.