diff options
author | 2003-04-01 16:05:36 -0700 | |
---|---|---|
committer | 2005-04-07 21:00:01 -0700 | |
commit | 70a399adbec9bc241786d8f143426210f0e83b56 (patch) | |
tree | 752ba1ce7af59d204f0bd6dcf87bc195752278ed /README | |
parent | Make conditional expressions handle compatible pointers. (diff) | |
download | sparse-70a399adbec9bc241786d8f143426210f0e83b56.tar.gz sparse-70a399adbec9bc241786d8f143426210f0e83b56.tar.bz2 sparse-70a399adbec9bc241786d8f143426210f0e83b56.zip |
Put a note in the README about the lazy type evaluation.
Diffstat (limited to 'README')
-rw-r--r-- | README | 21 |
1 files changed, 16 insertions, 5 deletions
@@ -26,17 +26,24 @@ And no, it doesn't use lex and yacc (or flex and bison). In my personal opinion, the result of using lex/yacc tends to end up just having to fight the assumptions the tools make. -The parsing is done in three phases: +The parsing is done in four phases: - full-file tokenization - pre-processing (which can cause another tokenization phase of another file) - semantic parsing. + - lazy type evaluation Note the "full file" part. Partly for efficiency, but mostly for ease of use, there are no "partial results". The library completely parses one whole source file, and builds up the _complete_ parse tree in memory. +Also note the "lazy" in the type evaluation. The semantic parsing +itself will know which symbols are typedefines (required for parsing C +correctly), but it will not have calculated what the details of the +different types are. That will be done only on demand, as the back-end +requires the information. + This means that a user of the library will literally just need to do struct token *token; @@ -58,6 +65,10 @@ This means that a user of the library will literally just need to do // Parse the resulting C code translation_unit(token, &list); + // Evaluate the types now if we want to + // Or leave it until later. + symbol_iterate(list, evaluate_symbol, NULL); + and he is now done - having a full C parse of the file he opened. The library doesn't need any more setup, and once done does not impose any more requirements. The user is free to do whatever he wants with the @@ -66,7 +77,7 @@ again. There is no extra state, there are no parser callbacks, there is only the parse tree that is described by the header files. The library also contains (as an example user) a few clients that do the -preprocessing and the parsing and just print out the results. These -clients were done to verify and debug the library, and also as trivial -examples of what you can do with the parse tree once it is formed, so -that users can see how the tree is organized. +preprocessing, parsing and type evaluation and just print out the +results. These clients were done to verify and debug the library, and +also as trivial examples of what you can do with the parse tree once it +is formed, so that users can see how the tree is organized. |