1

I'm writing an interpreter for C (subset) in Javascript (I want to provide program's execution visualisation in browser).

As the first step I want to create an AST tree for the user program. I'm using Jison for this, which is similar to flex/bizon combination.

For now I simply tokenize the program and parse to check if it conforms to the grammar given by the standard (let's leave alone the ambiguity problem introduced by typedef).

However conforming to C grammar doesn't guarantee that program makes any sense, for example

int main() {
    x = ("jklfds" || "jklgfd")(2, imlost);
}

conforms to the grammar, although x is not declared, ("jklfds" || "jklgfd") isn't a function pointer - types are not checked. In general there are many contextual conditions that aren't checked.

I'm wondering how much should I check while building the AST tree. For example, in theory at this point it would be easy to fully calculate and check constant expression. However, much of other checking requires context. Is it possible, for example, during parsing, to know that some identifiers refer to structs declared earlier in the program?

What about building the AST tree as is and checking contextual constrains by analyzing/transforming AST multiple times proving more and more conditions are correct? Will it be easier / harder than checking during parsing ?

I'm looking for the most friendly solution, I don't care for its speed.

kitek
  • 117
  • 1
  • 13
  • 1
    If you are building an AST, keep code that does context checks and code that does parsing fully separate and independent. It's your basic separation of concerns principle. – n. m. could be an AI Mar 10 '15 at 14:33
  • See http://stackoverflow.com/questions/243383/why-cant-c-be-parsed-with-a-lr1-parser/1004737#1004737 for a discussion of how to handle context-dependent constraints "cleanly". – Ira Baxter May 05 '16 at 06:27

0 Answers0