TkSee/SNExperiences with the parser

benchmark

IWPC 2002, Paris

S. Marchenko and T. Lethbridge

Parser Architecture

tkSee/SN parser

C/C++source

C/C++parser

SN DB

SN DBAPI

GXLFile(s)

SN 5.0parsing engine.

Cross-referencedata filePass 1.

generating code

information

TCL API

System calls

GXLgenerator

Direct codeinfo extractor

SN DBManager

Pass 2.generating

cross- reference

information

Source Navigator Database Structure

InheritancesGlobal variables

Constants

Enumerations

Inclusions

Enumerated constants

Function declarations

Instance variables

Function implementations

File symbols

Macros

Method declarations

Method implementations

Typedefs

Referenced-BY…

Referenced-TO…

Classes

TkSee/SN on the benchmark: Positive points

• Parser always produced output for all tests•No crashes

• Benchmark results can be easily recreated by other.• We use “free” software tools including our parser.• Answer-generation scripts are included along with the results).

• For “generated code” results we process the embedded code in the original lex/yacc source along with the generated results

TkSee/SN on the benchmark: Negative points.

• Accuracy and completeness of information extracted by parser was limited by supported language dialects:

•Not all examples were C++, K&R C, and ANSI C, which we support•Some tests were apparently from other dialects

•Not supported:• Pre-processing directives.• Namespaces • Operator overloading.

• Parser is not capable of “run-time” call resolution

Feedback on the benchmark (1)

•Benchmark helped us to fix a few bugs in our parser•Related to accuracy of results

•Additional questions added for this iteration were useful

•Extraction of positions information in terms of offset in bytes from the beginning of the source files:

•This was formally possible in TkSee•We moved away from it to line/character positions due to an attempt to conform to what everybody else is doing!

Feedback on the benchmark (2)

• “Heterogeneous” examples•E.g. combination of C/SQL•Benchmark should perhaps not ask about the content of the embedded language

•since the main intention of the test is comparison of C/C++ parsers.

• Some questions had to be answered rather indirectly•E.g. Number of Macros used to compute number of #define•DMM did not fully support some questions, but we could ‘stretch’ it!