Results of Running Acacia on the Parser Test Suite
	       ==================================================

			       by Michael Godfrey
				 November, 2001


===============================================================
./accuracy/preproc/2/answer.txt
===============================================================

> Question file for benchmark/accuracy/preproc/2

It refused to extract without the TRIGGER flag set, as expected.
    swag(70): ksh CCia preproc2.C 
    cpp: "preproc2.C", line 4: Expecting TRIGGER to be defined on the command line of the compiler.

When it did extract, I got a warning about the illegal use of macros
    swag(73): ksh CCia -D TRIGGER preproc2.C
    cpp: "jabberwock.C", line 1003: warning: __cplusplus: predefined symbol expanded outside of directive
    cpp: "jabberwock.C", line 1008: warning: __STDC__: predefined symbol expanded outside of directive


> 1. The following source line:
> 
> Answer:
>     cout << "The compilation occured at " << __TIME__ << " on " << __DATE__ << "\n";
> 
> occurs on which line and file?
> 
> If seen before preprocessor, it's line 14 of preproc2.C.
> 
> If seen before preprocessor, it's line 1001 of jabberwock.C.

Line 39 of a cref -u call returns the line number of the relationship.
The query asks for the line number of all uses of the macro __TIME__:

    swag(76): ksh cref -u - - m __TIME__ | cut -d ';' -f 39
    1001

> 2. How is the predefined macro __LINE__ represented in the parser output?

    swag(80): ksh cdef -u m __LINE__
    a08ebc1f;__LINE__;macro;;;;44;0;44;def;00000000;;;;;;;

It's a predefined macro not associated with any file (but apparently it does
have a line number of 46, whatever that means).


> 3. How is the predefined macro __STDC__ represented in the parser output?

It's a recognized macro name that is considered to be undefined.
    swag(81): ksh cdef -u m __STDC__
    4e20c78f;__STDC__;macro;;;;0;0;0;undef;00000000;;;;;;;


===============================================================
./accuracy/preproc/1/answer.txt
===============================================================

> Question file for benchmark/accuracy/preproc/1/
> 
> 1.  How many preprocessor directives are there?
> 
> Answer:
> When viewed as a text file:
> 
> 2	#include
> 17	#define
> 2	#ifdef
> 1	#elif
> 1	#else
> 1	#endif

This information is not modelled.  

Note that the "include" relationship between files is modelled:
    ksh cref f - f - file1!='/*'
This finds all includes (the only file-file relationship) ignoring those
including files whose name begins with a slash.

> 2. How many macros as defined?
> 
> Answer:
> When only DEFINITION_1 is defined: 6
> 	-TRIGGER and TRIGGER2 are not defined
> When only TRIGGER is defined: 5
> 	-TRIGGER_2 is not defined, DEFINITION_1 doesn't matter
> When TRIGGER and TRIGGER_2 are defined: 5
> When only TRIGGER_2 defined: 6
> 	-TRIGGER is not defined
> 	-same as DEFINITION_1

In short, acacia gets the correct answers 

Note that I include the defs of the DEFINITION_1, TRIGGER macros in my
counts, so my numerical totals are slightly off the official answers.

Note that the default call finds all macros defined by the compiler too.
	ksh cdef m -
To limit it to non-system files, we say this:
	swag(29): ksh cdef m - file!='/*' file!=''
This finds seven macros using the default extraction flags.
	TEXT REALTHING MFUNC CHUNK2 double DEFINITION_1 CHUNK1

> When only TRIGGER is defined: 5

You can pass macros defs to the extractor via the -D flag (and -U for
undefs) as in gcc and some other extractors.
	swag(31): ksh CCia -D TRIGGER preproc1.C
	swag(32): ksh cdef -u m - file!='/*' file!='' | cut -d ';' -f 2
	CHUNK1
	TEXT
	MFUNC
	DEFINITION_1
	CHUNK2
	REALTHING

> When TRIGGER and TRIGGER_2 are defined: 5
	swag(34): ksh CCia -D TRIGGER -D TRIGGER_2 preproc1.C
	swag(37): ksh cdef -u m - file!='/*' file!='' | cut -d ';' -f 2
	TEXT
	MFUNC
	DEFINITION_1
	CHUNK2
	REALTHING
	CHUNK1


> When only TRIGGER_2 defined: 6
	swag(38): ksh CCia -D TRIGGER_2 preproc1.C
	swag(39): ksh cdef -u m - file!='/*' file!='' | cut -d ';' -f 2
	MFUNC
	CHUNK2
	double
	DEFINITION_1
	CHUNK1
	TEXT
	REALTHING



> 3. How long (in lines) is test?
> 
> Answer:

Acacia gets the correct answers.  Fields 7 and 9 give the begin/end lines
of a function definition repsectively.

> When only DEFINITION_1 is defined: 8
    swag(46): ksh CCia preproc1.C
    swag(47): ksh cdef -u - test | cut -d ';' -f7,9
    20;27

> When only TRIGGER is defined: 3
    swag(48): ksh CCia -D TRIGGER preproc1.C
    swag(49): ksh cdef -u - test | cut -d ';' -f7,9
    56;58

> When TRIGGER and TRIGGER_2 are defined: 8

I assume you mean TRIGGER2, not TRIGGER_2
    swag(63): ksh CCia -D TRIGGER -D TRIGGER2 preproc1.C
    swag(64): ksh cdef -u - test | cut -d ';' -f7,9
    38;45

> 4. How long in characters is test?
> 
> Answer:
> When only DEFINITION_1 is defined: 173
> When only TRIGGER is defined: 79
> When TRIGGER and TRIGGER_2 are defined: 178

Not measured by acacia

> 5. How long (in lines) is main?
> 
> Answer:
> As text file: 15
> Other answers will depend on when the parser sees the input.

swag(59): ksh cdef -u - main | cut -d ';' -f7,9
73;87


===============================================================
./accuracy/preproc/pragma/answer.txt
===============================================================

> Question file for benchmark/accuracy/preproc/pragma
> 
> 1.  What line does main start on?
> 
> Answer:  line 76

swag(95): ksh cdef -u fu main | cut -d ';' -f 7
76

> 2. main declared one variable.  What is it?
> 
> Answer: int rc

Local variables are not modelled by acacia.

> 3.  Where is it used?
> 
> 	Line	Usage
> 	83		read and write
> 	89		read and write
> 	95		read and write
> 	98		read
> 	106		read

Local variables are not modelled by acacia.

> 4.  Where are the string constants in a04.cpp and how long are they?
> 
> Answer:
> 	Line	Length
> 	54		42
> 	62		44
> 	69		41
> 	79		30
> 	82		16
> 	88		17
> 	94		18
> 	100		13
> 	103		33

String constant values are not modelled by acacia.

> 5. How are the #pragmas represented in the parser output?

Pragmas are not modelled by acacia.


===============================================================
./accuracy/syntax/vars/answer.txt
===============================================================

> Question and answer file for benchmark/accuracy/syntax/vars
> 
> 1. The variable name "depth" has been used many times in this
> program.  Identify the distinct uses.

    swag(513): ksh cdef -u v depth | cut -d ';' -f 5,6,7,9,10,14,15
    int;regular;3;3;def;extern;
    int;regular;8;8;def;private;Local

This reveals two variables:  The global var on line 3 and the private data
member of Local at line 8.  CCia does not extract information about params
or vars local to a function.

As to use:
    swag(626): ksh cref -u - - v depth rkind=reference | cut -d ';' -f 3,4,22,27,39
    init;function;depth;8;28
    recurse;function;depth;8;36
    ~Local;function;depth;8;32
    main;function;depth;3;49.50

This shows that all uses of variables named "depth" are caught and resolved
to the correct variable (the output format is name of calling fcn, kind,
name of used var, line it's declared at, usage line numbers).

> Answer:
> Global variable defined on line 3, used on lines 49 and 50.
> Scope local variable defined on line 57, used on lines 57 and 58.
> Data member in class Local declared in line 8, used on lines 28, 32,
> and 37.
> Method/function parameter in Local::Local(int), Local::init(int),
> and Local::recurse(int). 
> 
> 2. What is the value of depth on line 50?  Where is this depth
> variable defined?
> 
> Answer:
> Its value is 8 and is defined on line 3.

Value is not modelled.  It is the depth defined on line 3:

    swag(822): ksh cref -u - - - depth file1=vars.C usage='*50*' | cut -d ';' -f 27
    3

> 
> 3. The method Local::recurse is overloaded.  How does the parser
> distinguish these two methods?  In particular, what are their
> function signatures?

CCia gets this correct.

This shows that there are two functions declared with name "recurse" whose
containment parent is class "Local".
    swag(518): ksh cdef -u - recurse def=dec ptype=Local | cut -d ';' -f 2,3,4,7,9
    recurse;function;vars.C;9;9
    recurse;function;vars.C;16;16

This query returns the return type and param list for each of the functions

    swag(826): ksh cdef -u - recurse def=dec ptype=Local | cut -d ';' -f 5,12
    void;(int)
    void;()

> 4. Both versions of Local::recurse use a depth variable.  Can
> these uses be resolved?  In other words, what variable is
> being used?
> Answer:
> Local::recurse() uses the data member depth declared on line 8.
> 
> Local::recurse(int) has depth as a function parameter to pass
> a value to the function, which is used inside the function.


This shows that the function recurse of no params uses the dept variable
declared at line 8.  The local variable use is not modelled by CCia.

    swag(832): ksh -u cref -u function recurse var depth | cut -d ';' -f 1,3,5,8,13,20,22,24,27
    function;recurse;vars.C;35;();variable;depth;vars.C;8


===============================================================
./accuracy/syntax/fcns/answers.txt
===============================================================

> Question file for benchmark/accuracy/syntax/fcns

In acacia, references/calls to functions are resolved to point of the
function's definition (not declaration) where possible.  So if f calls g,
acacia figures out which g this is an resolves the call/reference to the
point of g's definition (implementation).  However, this is obviously not
possible for library functions, so those are resolved to their declaration.


> 1.  In main(), an array of functions, fp, is defined.  Where
> are these functions defined and how are they found from
> main.C?
> 
> Answer:
> 
> Function	Defined	
> squared	squared.C	Found at link time (extern keyword)

    swag(254): ksh cdef -u fu squared | cut -d ';' -f 4,7,9,10,14
    main.C;6;6;dec;extern
    multiply.C;1;3;def;static
    squared.C;1;3;def;extern

There are three functions named "squared" in the system.  The first is an
extern declaration in main.C at line 6, the second is a static
(non-exported) definition in multiply.C from line 1 to 3, and the third is
an extern definition in squared.C from line 1 to 3.

If you want to know what function is called from file main.C, we phrase it
this way:

    swag(256): ksh cref -u - - fu squared file1=main.C | cut -d ';' -f 24,27,29,30,39,40
    squared.C;1;3;def;12;reference

This says that the function "squared" that is referenced (ie like a
variable, not called like a function) in file main.C is referenced at line
12.  The actual function whose definition is used is the one defined in
squared.C between lines 1 and 3.

> sqrt		math library	Via header

    swag(258): ksh cdef -u - sqrt | cut -d ';' -f 4,7,9,10
    /usr/include/bits/mathcalls.h;146;146;dec

sqrt is declared in this file.  Since it's a library function, it can't
find the definition of this function.

    swag(259): ksh cref -u - - fu sqrt file1=main.C | cut -d ';' -f 24,27,29,30,39,40
    /usr/include/bits/mathcalls.h;146;146;dec;12;reference

This says that the function "sqrt" referenced (as a variable) at line 12 of
main.C is the one declared in /usr/include/bits/mathcalls.h at line 146.

> tan		math library	Via header

    swag(260): ksh cref -u - - fu tan file1=main.C | cut -d ';' -f 24,27,29,30,39,40 
    /usr/include/bits/mathcalls.h;67;67;dec;12;reference

As above.

> fabs		math library	Via header

    swag(262): ksh cref -u - - fu fabs file1=main.C | cut -d ';' -f 24,27,29,30,39,40
    /usr/include/bits/mathcalls.h;165;165;dec;12;reference

As above

> triple	multiply.C	Found at link time (extern keyword)

    swag(263): ksh cref -u - - fu triple file1=main.C | cut -d ';' -f 24,27,29,30,39,40
    multiply.C;5;7;def;12;reference

The "triple" function referenced on line 12 is the one defined in
multiply.C between lines 5 and 7.

> whacked	multiply.C      Found at link time (extern keyword)

    swag(264): ksh cref -u - - fu whacked file1=main.C | cut -d ';' -f 24,27,29,30,39,40
    multiply.C;13;16;def;12;reference

The "whacked" function referenced on line 12 is the one defined in
multiply.C between lines 13 and 16.


> 2. In multiply.C, the function whacked calls the squared function.
> Which function does this call resolve to?
> 
> Answer:
> The squared function that is defined in multiply.C.

Same as last answer.  The resolution is correct.

> 3. Where is the type ptr2func define?  (Give your answer in bytes
> from start off file.)
> 
> Answer: 
> In sort.h, starting at 52 bytes, ending at 87 bytes (counting 
> from 0).

Acacia doesn't model byte-level information.

> 4. Where are the calls to triple?
> 
> Answer:
> File		Line	Function
> multiply.C	15		whacked
> sort.C		42		Sort::sort_for_x
> sort.C		47		Sort::compare
> sort.C		48		Sort::compare


    swag(276): ksh cref -u - - fu triple | cut -d ';' -f 3,5,39,40
    main;main.C;12;reference
    whacked;multiply.C;15;reference

The explicit call to triple in whacked is caught, as is the reference (like
a variable) in sort.C.  The other uses are implicit and not caught.


===============================================================
./accuracy/syntax/templates/answer.txt
===============================================================

Acacia cannot handle these template examples.  It dumped core when I tried
to do an extraction:

    swag(13): ksh CCia classmember-hacked.cpp
    cppia: ../cia++/ent_db.c:349: checkFn: Assertion `tp' failed.
    CCia: line 471: 5518: Abort
    swag(14): ksh CCia function-hacked.cpp
    cppia: ../cia++/ent_db.c:349: checkFn: Assertion `tp' failed.
    CCia: line 471: 5529: Abort

This has been reported to the Acacia team, and the concur that's it's a
bug.

> Question file for benchmark/accuracy/syntax/templates
> 
> classmember.cpp
> 
> 1. Where are templates used in this file?
> 
> Answer:
> i) To create a templated class foo.
> ii) To create a template member function f<T>::doStuff
> 
> 2. How many versions of class foo are created.
> 
> Answer:
> Two, one of type int and another of type <complex<float>>.
> 
> 3. The member function doStuff is called twice on lines 29 and 30
> from the same object.  Compare and contrast representation of
> these calls to doStuff in the parser output.
> 
> function.cpp
> 
> 4. How many versions of the factorial function are created?
> 
> Answer: 15 (One for each number 0-14.)
> 
> 5. Does this large number of version affect the size of your
> parser output?
> 
> 6. How is the generic template type <> represented in the
> parser output?
> 


===============================================================
./accuracy/syntax/array/answer.txt
===============================================================

> Question file for benchmark/accuracy/syntax/array
> 
> In main(), calls are made to the constructor for the Polynomial
> class and to plotpoint.  One of the arguments to the constructor is 
> a pointer to a float and one of the arguments to plot point is 
> a reference to an object.
> 
> 1. Contrast how the parser represents these two data references.

Acacia doesn't model calls to constructors and destructors correctly; I
think this is a bug.

It does extract correct information about where [con|de]structors are
defined; they are simple considered to be function named, say, "Polynomial"
and "~Polynomial".

When you ask to see all uses of the constructor to Polynomial, it finds
them if you declare the object on the stack:
    swag(134): ksh cref -u - - fu 'Polynomial' rkind=reference | cut -d ';' -f 5,39
    main.C;12.13.14
So it catches the uses at lines 12-14 in main.c.  But if you call the
constructor via "new", this call is missed:
    Polynomial *pp1;
    pp1 = new Polynomial (1,c1);
    pp1 -> describe();
    delete pp1;
The call to describe() is caught, but the call to the constructor is missed.

Calls to the constructor should be modelled, but they are incorrectly
resolved to the points of instantiation:
    swag(147): ksh cref -u - - fu '~Polynomial' rkind=reference | cut -d ';' -f 5,39 
    main.C;12.13.14


> 2. Contrast how the parser represents the parameters to these two
> functions.

The use of actual parameters are not modelled.  However, the formal
parameters record a use of the parameter type in the definition of the
method/function:

    swag(165): ksh cdef -u fu Polynomial ptype=Polynomial def=def | cut -d ';' -f 4,5,7,12
    poly.C;Polynomial &;7;()
    poly.C;Polynomial &;13;(int, float *)

This says that there are two definitions of a function named "Polynomial"
that is owned by a parent type named Polynomial.  They occur in file
poly.C at lines 7 and 13.  They both return a reference to a Polynomial but
they have two different param type lists.

    swag(155): ksh cdef -u fu plotpoint | cut -d ';' -f 5,12
    void;(Polynomial *, float)

This says that plotpoint returns a void, and has param list 
"(Polynomial *, float)"

> Inside the  Polynomial class arrays are traversed in two ways; one way is
> using pointer arithmetic (poly.C, line 23) and the other is using array
> indexes (poly.C, line 36).
> 
> 3. Does the parser distinguish between uses of the data structure as a
> whole (e.g. coeffs) and uses of individual elements in the data structure
> (e.g. coeff[1]).

In Polynomial::init, coeffs is a parameter, so all references to the name
"coeffs" are ignored; however, references to the member variable
"this->coeffs" are all caught correctly.  In Polynomial::value, coeffs is
not a param, thus references to this name resolve to the member variable;
all such references are caught correctly.

But to answer the question, no.  No such deep analysis is performed.


> 4. Contrast how these two styles of array traversal are represented in
> the parser output.

They aren't modelled; all that is caught are calls to functions/macros, 
references to non-local variables, and type uses.


===============================================================
./accuracy/syntax/operators/answer.txt
===============================================================

> Question file for benchmark/accuracy/syntax/operators
> 
> addition.cpp
> 
> 1. In this file, the addition operator has been overloaded for 
> class foo.  Where is this done?  Where is it used?
> 
> Answer:
> foo operator+(const foo &other) is defined inside the foo class
> definition on lines 13-17.  It is an implicit inline member
> function.
>
> It is called in main on lines 23 and 24 (twice). 

First, note that Acacia's EDG front end can't handle "std::", so I have
hacked it out of the source.  I uniformly changed the filename foo.cpp to
foo-hacked.cpp when I had to do this.

To find the definition of the overloading:L
    swag(396): ksh cdef -u fu operator+ | cut -d ';' -f 2,3,4,7,9,10
    operator+;function;addition-hacked.cpp;13;16;def
There is a function called "operator+" in addition-hacked.cpp running from
line 13 to 16.

To find its uses:

    swag(400): ksh cref -u - - fu operator+ file2=addition-hacked.cpp rkind=reference | cut -d ';' -f 39
    22.23

So it's used on lines 22 and 23.


> fcall.cpp
> 
> 2. In this file, the function call operator has been overloaded
> for class foo.  Where is this done?  Where is it used?
> 
> Answer:
> double &operator()(int i,int j)  is defined inside the foo class
> definition on lines 12-16.  It is an implicit inline member function.

This query finds all operators in the file.  

    swag(414): ksh cdef -u - 'operator*' file=fcall-hacked.cpp | cut -d ';' -f 2,3,5,7,9,10,12
    operator();function;double &;12;15;def;(int, int)

So the () operator returns a double ref and takes two ints; it is defined
between lines 12 and 15.

> It is used in main on lines 22 and 23.

    swag(426): ksh cref -u - - - 'operator*' file2=fcall-hacked.cpp rkind=reference | cut -d ';' -f 1,3,5,22,39
    function;main;fcall-hacked.cpp;operator();21.22

The only operators defined in fcall-hacked.cpp that are used is
"operators()", which is used on lines 21 and 22.  So yes, it finds the
correct lines.


===============================================================
./accuracy/syntax/inherit/answer.txt
===============================================================

> Question file for benchmark/accuracy/syntax/inherit
> 
> 1. The classes Mover and Sayer both appear at the top of a
> class hierarchy.  Compare and contrast how these two are
> represented in the output.
> 
> Answer:
> 
> Mover is a virtual class.  First, it has a virtual function 
> (move()). Second, it dominates a class hierarchy, so it is 
> sub-classed using the virtual keyword by all its child classes 
> (Walker, Swimmer, and Flier).

First see the beautiful job of auto-layout done by the acacia tool (it uses
the well known graphviz package from AT&T research):  inh.[ps,gif]

The query used was, roughyl speaking
	% ksh cref -u - - - - tclass1=class tclass2=class file1!='/*'

As far as the answer goes, I think you have some misconceptions about C++
inheritance.  "Virtual inheritance" is used only when there's a danger of
multiple inheritance.  Virtual methods, on the other hand, tell the
compiler to use dynamic dispatch to figure out which method to call
(roughly speaking, this is the only way Java does dispatch).

The question is not clear (I don't know what you mean by "virtual class"),
so I will interpret this as "what can you tell me about Mover and Sayer".  
Since they are similar, I'll just do Sayer.

    swag(317): ksh cdef -u t Sayer | cut -d ';' -f 3,4,6,7,9
    type;Sayer.H;class;5;13

Sayer is a typedef; in particular, it's a class declared in Sayer.H between
lines 5 and 13.

    swag(321): ksh cdef -u - - ptype=Sayer | cut -d ';' -f 2,3,4,7,9,10
    utterance;variable;Sayer.H;7;7;def
    Sayer;function;Sayer.H;10;10;dec
    Sayer;function;Sayer.H;11;11;dec
    say;function;Sayer.H;12;12;dec
    Sayer;function;Sayer.C;8;10;def
    say;function;Sayer.C;12;14;def
    Sayer;function;Sayer.C;4;6;def
    Sayer;function;Sayer.H;10;10;dec
    Sayer;function;Sayer.H;11;11;dec
    say;function;Sayer.H;12;12;dec

This shows all of the subparts of Sayer, including the methods, variables,
and [con|de]structors.


> 2. In main(), the Flier class is instantiated using an object
> pointer (and the new keyword), while the ObedientSayer class 
> is instantiated as a variable. Compare and contrast how these
> two styles of instantiation are represented in the output.

Acacia spots calls to the constructor when direct creation is used (ie for
stack-based objects), but alas not for heap-based objects (ie via "new").
I have reported this as a bug; I believe it is supposed to work.
I don't believe that there would be any distinction between heap-based and
stack-based instantiation.

    swag(335): ksh cref -u - - fu ObedientSayer ptype2=ObedientSayer rkind=reference | cut -d ';' -f 5,39
    animals.C;32

This says that the constructor ObedientSayer (a function named
ObedientSayer that is contained by the type ObedientSayer) is called only
on line 32 of file animals.C.

    swag(333): ksh cref -u - - fu Flier rkind=reference | cut -d ';' -f 5,39
    swag(334): 

Thus no call to the a constructor of Flier was found.


> 3. How many classes does Duck inherit from?
> 
> Answer:
> Directly, two, Avian and Quacker. 
> Indirectly, many more and depends on how you count.
> 	Avian
> 	Swimmer
> 	Flier
> 	Biped
> 	Mover (three times, virtually)
> 	Quacker
> 	NoisySayer
> 	Sayer

    swag(341): ksh cref -u t Duck - - tclass1=class tclass2=class rkind=inheritance | cut -d ';' -f 22
    Avian
    Quacker

Thus Duck inherits (directly) from Avian and Quacker.


> 4.  The ObedientSayer class has two friend funtions, pet and squeeze.
> Explain how pet is represented in the parser output.  In particular,
> comment on how the uses of variables in the function body are resolved.

First, the definition of pet is simple to model:
    swag(64): ksh cdef -u fu pet | cut -d ';' -f 3,4,5,7,9,10,12
    function;Sayer.H;void;31;31;dec;(ObedientSayer &)
    function;Sayer.C;void;38;46;def;(ObedientSayer &)
pet is a void function  of an ObedientSayer ref declared in Sayer.H on line
31 and defined in Sayer.C between lines 38 and 46.

    swag(354): ksh cref -u - - v currFreq ptype2=ObedientSayer rkind=reference | cut -d ';' -f 1,3,5,39
    function;squeeze;Sayer.C;50.52
    function;pet;Sayer.C;40.42

This shows that all uses of the variable currFreq that is a part of
ObedientSayer occur within two functions:  squeeze at lines 50 and 52, and
pet at lines 40 and 42.  That is, the resolution is correct.


    swag(361): ksh cref -u - - - - file1!='/*' file2!='/*' def1=def rkind=friendship | cut -d ';' -f 3,4,5,22,23,24
    squeeze;function;Sayer.C;ObedientSayer;type;Sayer.H
    pet;function;Sayer.C;ObedientSayer;type;Sayer.H

This shows all friendship relationships in non-system files:  squeeze and
pet are friends of ObedientSayer.




===============================================================
./accuracy/syntax/struct/answer.txt
===============================================================

> Question file for benchmark/accuracy/syntax/struct
> 
> 1. What are the contents of struct BUSY?
> 
> Answer:  A variable of type int, a variable of type float,
> and a function of type int(float).

    swag(445): ksh cdef -u - - ptype=BUSY | cut -d ';' -f 2,3,5,12
    a;variable;int;
    b;variable;float;
    c;function;int;(float)

Yup.

> 2. Contrast how variables and functions inside structs are
> represented in the parser output.

The parent type (BUSY) may contain subparts if it is a class, struct, enum,
or union.  To see the subparts of a parent, just name the parent with the
ptype attribute.

> 3. An anonymous struct is defined on line 3.  Contrast its
> representation with that of struct BUSY in the parser output.

A unique name is generated automatically.  Here are all of the fields for
the two structs:
    swag(450): ksh cdef -u t - file=struct.C tclass=struct
    19a7c9fc;BUSY;type;struct.C;;struct;4;0;4;def;00000000;;;extern;;;struct BUSY;
    8c90382b;type-3-8;type;struct.C;;struct;3;0;3;def;00000000;;;extern;;;struct <unnamed>;



===============================================================
./accuracy/syntax/union/answer.txt
===============================================================

> Question file for benchmark/accuracy/syntax/union
> 
> 1.  What are the global variables in this program?  
>
> Answer: fighter, bomber, and transport the globals.  

    swag(470): ksh cdef -u v - file=union.cpp scope=extern | cut -d ';' -f 2,4,7
    bomber;union.cpp;15
    fighter;union.cpp;15
    transport;union.cpp;15

The three global (scope=extern) variables are bomber, fighter, transport;
all are declared on line 15.

> 2.  What are the local variables in this program?
> 
> Answer:  There are no local variables.

Acacia does not extract information about local variables.

> 3. How big (in memory units) is the union inside aircraft?
> 
> Answer: 4 bytes

Acacia does not extract this kind of information.

> 4. How big is the aircraft struct?
> 
> Answer: 8 bytes

Acacia does not extract this kind of information.

> 5. Where are the variables from the union used?
> 
> Answer:
> 	Line	Variable
> 	21		fighter.fuel_load
> 	25		bomber.bomb_load
> 	31		transport.fuel_load
> 	32		fighter.pallets
> 	35		fighter.pallets
> 	36		bomber.bomb_load

To find the union types:

    swag(482): ksh cdef -u - - file=union.cpp tclass=union | cut -d ';' -f 2,3,4,7,9,15
    type-10-10;type;union.cpp;10;14;aircraft

This says that there is one union type defined in union.cpp.  It is not
named (so a name was generated for it: "type-10-10").  It is defined
between lines 10 and 14, and it is a subpart of the type "aircraft".
To find the subparts of this type:

    swag(486): ksh cdef -u - - ptype=type-10-10 | cut -d ';' -f 2,3,5,7,9,15
    pallets;variable;int;13;13;type-10-10
    bomb_load;variable;float;12;12;type-10-10
    fuel_load;variable;float;11;11;type-10-10

So pallets, bomb_load, and float are subparts of the union, defined at line
13, 12, 11 resp. 

To find the uses of all subparts of this union:

    swag(492): ksh cref -u - - - - ptype2=type-10-10 rkind=reference | cut -d ';' -f 3,4,5,22,39
    main;function;union.cpp;fuel_load;21.31
    main;function;union.cpp;pallets;29.32.34
    main;function;union.cpp;bomb_load;25.35

The main function uses fuel_load at lines 21 and 31, pallets at lines 29,
32, and 34, and uses bomb_load at lines 25 and 35.

Note that the line numbers seem to be off by one from the expected answers.
This seems to be a bug in Acacia.





===============================================================
./accuracy/syntax/enum/answers.txt
===============================================================

> Question file for benchmark/accuracy/syntax/enum
> 
> 1.  This test bucket contains a C and C++ version of the same
> program.  In C++, you can't iterate through an enum using a
> variable of that type; in other words, the ++ operator is not
> defined for enum types.  Does your parser accept both files
> or only one?  What does it produce for the C version? 

There are three options for extractors in the Acacia toolkit:

1. "cia", the older C extractor.  This performs perfectly on the C version
    and catches both references to SAT and the one reference to SUN in
    main.  However, it doesn't support C++.

2. "CCia", the usual C++ extractor, using the default C++ mode.  This
    (correctly) rejects the C version and accepts the C++ version.
    However, it misses the references to SAT and SUN on lines 6 and 14.
    This is a bug in Acacia and has been reported.

	swag(199): setenv CC g++
	swag(200): ksh CCia enum.c
	"enum.c", line 14: error: enumerated type is not allowed
	     for (day = SUN; day <= SAT; day++)
					 ^
	1 error detected in the compilation of "/tmp/ciatmp23215/tmp".
	swag(206): ksh CCia enum.cpp
	swag(208): ksh cref -u - - - SAT rkind=reference
	swag(209): ksh cref -u - - - SUN rkind=reference
	swag(210): 

3.  "CCia", the usual C++ extractor, using C mode.  This parses the C
    version.  The extractor gets the reference to SAT on line 14 and misses
    the other ref to SAT and SUN.  This is likely a bug; I have informed
    the developers.

	swag(188): setenv CC gcc
	swag(189): ksh CCia enum.c
	swag(197): ksh cref -u - - - SAT rkind=reference | cut -d ';' -f 39,40
	14;reference
	swag(198): ksh cref -u - - - SUN rkind=reference | cut -d ';' -f 39,40
	swag(199): 



> 2.  What is the fourth enumeration constant in enum days?
> 
> Answer: WED

This information is not modelled.

> 3.  What is the (integer) value of of enumeration constant
> MON?
> 
> Answer: 2

This information is not modelled.


===============================================================
./accuracy/syntax/namespace/answers.txt
===============================================================


> Question file for benchmark/accuracy/syntax/namespace
> 
> 1. How many namespaces are defined using the keyword namespace?
> 
> Answer:  Three: Beta, Delta, and Epsilon

Acacia does not handle namespaces.

> 2. How many namespaces can be accessed from inside main()?
> 
> Answer:
> 
> Global
> local to file main.C
> local to function
> struct Alpha (included using ns.H)
> class Gamma (included using ns.H)
> namespaces Beta, Delta, and Epsilon (included using ns2.C)

Acacia does not handle namespaces.

> 3. Where is Gamma::setValue declared?  Where is it defined?
> 
> Answer:
> 
> It is declared in ns.H on line 15.  It is defined in ns.C on
> lines 11-13.

Acacia does not handle namespaces.



===============================================================
./accuracy/syntax/exceptions/answers.txt
===============================================================

> Question file for benchmark/accuracy/syntax/exceptions
> 
> 1. Where are the try/catch blocks in exception.cpp?  How are
> they represented in the parser output?
> 
> Answer:
> Inside Xhandler, try (lines 11-14) and catch (lines 15-16, and 18-21).

The extractor correctly parses the program, however ...

Acacia does not go below the "external declaration" level; this information
is not modelled.  Note also that acacia does not model exceptions objects
either as the extractor was built before this was common.

> 2. What types of exceptions can be caught?
> 
> Answer:
> int and char*

The information is not modelled.

> 3. How is the relationship between try and catch blocks represented
> in the parser output?  In other words, how can you tell which 
> set of catch blocks catch exceptions thrown by a try block.

The information is not modelled.  There are no interesting relationship at
any of the try/catch lines:
    swag(233): ksh cref -u - - - - file1=exception.cpp usage='*19*'
    swag(234): 



===============================================================
./robustness/generated/lexyacc/answer.txt
===============================================================

> Question file for benchmark/robustness/generated/lexyacc
> 
> This test case consists of the input files to lex and yacc,
> two common programs used to generated lexical analysis and
> parsing tools in C.  (In fact, it's not entirely straightforward
> to get their output to work with C++. Comparable tools are 
> available to generate lexers and parsers for C++, but these
> don't yet.)  This pair was selected because they are widely
> used.  Also, the test bucket consists of .l and .y files  
> because they are the maintenance artifacts rather than the
> generated C code.
> 
> 1. Both .l and .y files have their own internal syntax and
> consist of sections.  Both have sections consisting of C
> code.  Is your parser able to wade through the sections and
> make sense of the C code?
> 
> 2. Does the generated source have any characteristics not commonly
> found in hand crafted code?
> 
> 3. Does the parser make note of any relationships between data
> in the .l, .y, and resulting .c and .h files?  


Acacia cannot parse the files.  I did take the liberty of doing a make,
and Acacia was able to parse the resulting .c files (but only in C mode; it
flunked in C++ mode).


===============================================================
./robustness/generated/stateflow/answer.txt
===============================================================

> Question file for benchmark/robustness/generated/stateflow
> 
> Example excerpted from:
> http://www.mathworks.com/company/digest/december00/codegen.shtml
> 
> Stateflow for PalmOS takes .mdl files that contain state charts
> and creates source code that can be compiled for the Palm
> platform.
>  
> The state charts are created using MATLAB 6, Simulink 4, Stateflow 4, 
> or Stateflow Coder 4; available at http://www.mathworks.com 
> The generated code is expected to compiled with CodeWarrior for Palm 
> Computing« Platform, Release 6, full or 'lite' version;
> available at http://www.palmos.com 
> 
> The state charts and user created files are found the current directory.
> If they are needed additional files are available from the Metrowerks 
> project files (in stateflow.zip) and the generated files (in the
> generated subdirectory).  Note that the generated files can also
> be found in the zip file.
> 
> 1. Were you able to do anything with the initial set of files?

Nope.


> 2. Results of parsing and analysis are often display visually.
> Can the Stateflow diagrams be used to assist this process? 
> 


===============================================================
./robustness/hetero/cfortran/answer.txt
===============================================================

> Question file for benchmark/robustness/hetero/cfortran
> 
> 1. How does your parser represent the extern "C" { ... } construct?

It treats these as function declarations.

    swag(142): ksh cdef -u - '*_' file=number.C
    2dab926f;fsquare_;function;number.C;void;regular;9;0;9;dec;00000000;(int *, int *);;extern;;;;
    6142bf85;fcube_;function;number.C;int;regular;10;0;10;dec;00000000;(int *);;extern;;;;


> 2. Can it handle other calling constructs, e.g. for Pascal or Cobol?

Unknown; give me an example and I'll tell you.

> 3. There is an "asm" keyword in C.  How does your parser deal with
> assembler code in a C file?

Unknown; give me an example and I'll tell you.

> 4. Does your parser produce any output for the Fortran file?

Nope.


===============================================================
./robustness/hetero/esql/answer.txt
===============================================================

> Question file for benchmark/robustness/hetero/esql
> 
> t2.pc is C program created using Pro*C.  There are a couple of
> "normal" parser issues plus the embedded SQL. 
> 
Acacia was unable to parse this file.  It could recorgnize "varchar" and
then got further conhfsued by the SQL.

Acacia requries clean compilable C or C++.  No embedding of "other stuff".

> 1. There is some information that is missing, such as the
> definition of the varchar [] data type and calls to the
> sqlca library.  Were there others?
> 
> 2. There are a number of EXEC SQL statements.  How does your parser
> deal with these?
> 
> 3. There are some SQL scripts included in the test bucket.  Is
> any of the information in these files used, for example to
> track data?


===============================================================
./robustness/missing/header/answer.txt
===============================================================

> Question file for benchmark/robustness/missing/header
> 
> 1. In this test bucket, a header file is missing.  Can your
> parser still generate output?

Acacia does not require complete source in the sense that .c/.cpp/.C/.cc
files can be missing, but included headers may not be missing or the
extractor will die.

> 2. Alpha and Gamma are two very similar data structures, but one is a
> class and the other is an object.  How does the parser deal with this
> ambiguity?

Can't tell.  First problem was enough to kill it.

> 3. Is there any source that is missing other than the header?

Can't tell.  First problem was enough to kill it.


===============================================================
./robustness/missing/source/answer.txt
===============================================================

> Question file for benchmark/robustness/missing/source
> 1.  The file CardPile.cc is missing.  Was the existence of CardPile.h
>     enough to allow your extractor to perform a "full" extraction?

Sure, no problem.  Entities declared in the .h file and defined in the
missing .cc file are resolved to the declarations instead.  Normally, if f
calls g, the call is resolved to the correct implementation.

> 2.  The main function calls deck->shuffle().  How did your extractor
>     resolve this reference?
> 
>     That is, shuffle() is a method of CardPile, whose definition file is
>     missing.  deck is an instance of Deck which inherits from CardPile and
>     does not override shuffle.  What did your extractor say?

    swag(152): ksh cref -u fu main fu shuffle | cut -d ';' -f 24,27,29,35
    CardPile.h;22;22;CardPile

It is resolved to CardPile::shuffle. Normally this would resolve to the
definition, but that file is missing, so it resolves to the declaration in
CardPile.h on line 22.

> 3.  CardPile inherits from vector<Card*>.  How did your extractor model
>     this inheritance from a templated class?


    swag(158): ksh cref -u t CardPile - - rkind=inheritance | cut -d';' -f 20,22,26,33
    type;vector;tplclass;<Card *, alloc>

CardPile inherits from templated class vector; field 33 gives the template
incntation  (the second arg is actually optional).

> 4.  What are the names of the "const" functions defined by Player?
> 
>     ANSWER:	getName, getPlayerToMyLeft, getPoints, printHand, 
>     		hasTwoOfClubs

The Acacia output has a field called "spec" for functions that is a short
string.  The letters it can contain are "c" (const function), "v"
(virtual), "i" (inline), and "s" (static).  A static inline function would
be "si" and an inlined virtual const function would be "ivc".  The order is
not specified anywhere, so I matched against "*c*" in this field.

    swag(550): ksh cdef -u fu - spec='*c*' def=dec ptype=Player | cut -d ';' -f 2 | sort -u
    getName
    getPlayerToMyLeft
    getPoints
    hasTwoOfClubs
    printHand



> 5.  What is the name of the "pure virtual" (ie abstract) function defined
>     by Player?
> 
>     ANSWER: 	playCard 

Acacia can't detect pure virtual functions per se (tho doubtless this could
be added as a feature).  Instead, one could look for all virtual functions
of Player that are declared (def=dec) and then see which of those are not
also defined (def=def).  This is not quite the same thing, but it's close.

    swag(558): ksh cdef -u fu - ptype=Player spec='*v*' def=def | cut -d ';' -f 2 | sort -u > defs
    swag(559): ksh cdef -u fu - ptype=Player spec='*v*' def=dec | cut -d ';' -f 2 | sort -u > decs
    swag(560): diff defs decs
    7a8
    > playCard

> 6.  What functions are defined by SmartPlayer and not used in any other
>     class?  (Clearly private functions are obvious candidates, but suppose
>     there were other public or protected functions that just happen not to
>     be called by any one else.  How would you express such a query?)
> 
>     ANSWER:     findARandomCard, followSuit

To grab an alphabetized list of functions of SmartPlayer:

    swag(576): ksh cdef -u fu - ptype=SmartPlayer | cut -d ';' -f 2 | sort -u > smartplayerFuncs

To find the instances of all uses of functions of SmartPlayer exluding
calls by other members of SmartPlayer:

    swag(581): ksh cref -u - - fu - ptype1!=SmartPlayer ptype2=SmartPlayer rkind=reference | cut -d ';' -f 22 >  smartplayerFuncsUsedExternally

Now diff the list:

    swag(583): diff smartplayerFuncs*
    1,5d0
    < findARandomCard
    < followSuit
    < playCard
    < SmartPlayer
    < ~SmartPlayer

So why the difference between this and the correct answer? 

First, as discussed, Acacia does not correctly catch uses of
[con|de]structor calls when using heap based objects (ie via new/delete),
which is what is done in the main function.

Second, recall that playCard is a pure virtual function declared in the
parent Player class and implemented in the two concrete child classes,
SmartPlayer and RandomPlayer.  The only place where any version of this is
invoked is on line 94 of main.cc.  This call is resolved as a call to the
parent class since the static type of the calling object is a (pointer to)
Player.

> 7.  Is there any non-public inheritance?  How would you find out?
> 
>     ANSWER: no

    swag(593): ksh cref -u - - - - rkind=inheritance file1!='/*' pkind!='' | cut -d ';' -f 3,22,42

Inheritance is modelled as a relationship between classes.  The
relationship attribute "pkind" indicates the kind of inheritance:
"private", protected", or "" for public.

To see if there's any non-public inheritance anywhere in the system, we do
this:
    swag(596): ksh cref -u - - - - rkind=inheritance pkind!='' | cut -d ';' -f 3,5,22,24,42
    streammarker;/usr/include/g++-2/streambuf.h;_IO_marker;/usr/include/libio.h;private

So we can see that the system class streammarker inherits privately from
_IO_marker.


> 8.  What file and at which line number does the declaration for the
>     destructor of Deck begin?  the definition?
> 
>     ANSWER:  declaration: line 14 of Deck.h, definition: line 24 of Deck.cc

    swag(601): ksh cdef -u fu '~Deck' | cut -d ';' -f 4,7,9,10
    Deck.cc;24;28;def
    Deck.h;14;14;dec

The declaration is on line 14 of Deck.h and the definition is between lines
24 and 28 of Deck.cc.

> 9.  Are there any non-virtual methods in any of the classes?  How did you
>     find out?
> 
>     ANSWER: No.

The "spec" attribute is the key here:

    swag(608): ksh cdef -u fu - file!='/*' spec!='*v*' file!='' def=dec | cut -d ';' -f 2,4,15
    operator==;Card.h;Card
    CardPile;CardPile.h;CardPile
    Deck;Deck.h;Deck
    operator==;Card.h;Card
    operator<<;Card.h;
    Deck;Deck.h;Deck
    Trick;Trick.h;Trick
    Player;Player.h;Player

This query reveals only operators and constructors.  No normal methods are
non-virtual.


> 10. Are there any inline methods (either declared as inline or just
>     inlined)?
> 
>     ANSWER: Yes, the constructors and destructors for SmartPlayer,
> 	    RandomPlayer, and Card

Acacia gets the correct answers.  Once again, the key is using the "spec"
attribute:

    swag(610): ksh cdef -u fu - file!='/*' spec='*i*' file!='' | cut -d ';' -f 2,4,15
    Card;Card.h;Card
    ~Card;Card.h;Card
    SmartPlayer;SmartPlayer.h;SmartPlayer
    ~SmartPlayer;SmartPlayer.h;SmartPlayer
    RandomPlayer;RandomPlayer.h;RandomPlayer
    ~RandomPlayer;RandomPlayer.h;RandomPlayer



===============================================================
./robustness/missing/library/answer.txt
===============================================================

> Question file for benchmark/robustness/generated/vacpp
> 
> The source code in this test buck has been generated by VisualAge
> C++ and includes a GUI created by the IBM Open Class Library that
> is missing.  (To be completely accurate, the header files are 
> missing as well and the code uses some VAC++ compiler extensions as
> well.) Consequently is it being used as an example of generated source 
> code and as missing a library.  

Acacia was not able to deal with the missing include files. 
End of story.

> Questions 1 and 2 focus on issues associated with a missing library. 
> Questions 3-5 focus on generated source code.  The remaining
> questions concern general aspects of the output.
> 
> 1. Was your parser able to generate output for this test bucket?
> 
> 2. How does it deal with the missing library?
> 
> 3. Did the unusual file suffixes cause any problems for your parser?
> 
> 4. Was there unusual features in the code or parser output to 
> distinguish it from manually generated source?
> 
> 5. How does the parser handle the resource files (.RC, RCI, .RCX. VBB)?
> 
> 6. Which classes are declared in these files?  Where?
> 
> Answer:
> 	Hello				Hello.hpp, lines 14, 35-79
> 	HelloConn0			Hello.cpp, line 28-67
> 	ICanvas				Hello.hpp, line 23
> 	IPushButton			Hello.hpp, line 25
> 	IStaticText			Hello.hpp, line 24
> 	IVBConnectionList	Hello.hpp, line 21
> 
> 
> 7. What are the public methods in the Hello class?
> 
> Answer:
>    Hello(
>       unsigned long id = WND_Hello,
>       IWindow* parent = IWindow::desktopWindow(),
>       IWindow* owner = 0,
>       const IRectangle& rect = defaultFramingSpec(),
>       const IFrameWindow::Style& style = IFrameWindow::defaultStyle ( ),
>       const char* title = defaultTitle());
>    virtual  ~Hello();
>    static const IRectangle defaultFramingSpec();
>    static IString defaultTitle();
>    virtual Hello & initializePart();
>    Hello * getFrameWindow() { return this; };
> 
> 
> 8.  Where are these methods defined?
> 
> Answer:
>    Hello				Hello.cpp, line 91-123
>    ~Hello				Hello.cpp, line 128-135
>    defaultFramingSpec	Hello.cpp, line 91-123 
>    IString defaultTitle	Hello.cpp, line 83-86
>    initializePart		Hello.cpp, line 140-145
>    getFrameWindow		Hello.hpp, line 56
> 
> 
> 9.  The Hello class has a private member data called iCanvas.  What is its
> type and where is it used?
> 
> Answer:
> Its type is ICanvas.  It is used in the following places and ways.
> 
> Location				Usage	Function
> Hello.cpp, line 102		write	Hello::Hello
> Hello.cpp, line 109		read	Hello::Hello in call to IStaticText::IStaticText
> Hello.cpp, line 110		read	Hello::Hello in call to IStaticText::IStaticText
> Hello.cpp, line 114		read	Hello::Hello in call to IPushButton::IPushButton
> Hello.cpp, line 115		read	Hello::Hello in call to IPushButton::IPushButton
> Hello.cpp, line 121		read	Hello::Hello in call to IFrameWindow::setClient
> Hello.cpp, line 134		write	Hello::~Hello
> Hello.cpp, line 153		read	Hello::makeConnections
> 


===============================================================
./robustness/dialects/g++/answer.txt
===============================================================

> Question file for benchmark/robustness/dialects/g++
> 
> 1. Both initp1.C and packed1.C use g++'s __attribute__()
> extension.  How does your parser represent this construct?

    swag(36): ksh CCia initp1.C
    swag(37): ksh cdef -u - __attribute__
    30fdcae6;__attribute__;macro;;;;0;0;0;undef;00000000;;;;;;;

It's a predefined macro.  Acacia does a probe of each compiler the first
time that it is used and stored information about it such as predefined
macros.

`
> 2. In initp1.C,  class Two has a data member count.
> Where is count declared? Where is count initialized?
> 
> Answer:
> count is declared on line 9 and initialized on line 50.

    swag(39): ksh cdef -u - count | cut -d ';' -f 3,4,7,9,10
    variable;initp1.C;9;9;dec
    variable;initp1.C;50;50;def

So count is a variable that is declared at like 9 of initp1.C and defined
(initialized) atline 50 of initialized.C.

> 3. Hexadecimal numbers appear on lines 66, 69, 72, 80 and 88.  How does
> the parser represent hex numbers in its output?

Acacia does not model data values.


===============================================================
./robustness/dialects/msvcpp/answer.txt
===============================================================

> Question file for benchmark/robustness/dialects/msvcpp
> 
> This test case has been taken, with permission, from the collection
> of test buckets for VisualAge C++ for AIX and for NT compiler.
> It is used to test acceptance of MS VC++ compiler extensions.
> 
> 1. test2.c uses Microsoft Visual C++'s __cdecl keyword.  How
> does the parser handle this?

If Acacia had been able to find and probe this compiler, it would likely
have been able to handle this feature.  As it is, it has no idea what this
macro is, and so can't parse the file.  


===============================================================
./robustness/dialects/vacpp/answer.txt
===============================================================

> Question file for benchmark/robustness/dialects/vacpp
> 
> This test case has been taken, with permission, from the collection
> of test buckets for VisualAge C++ for AIX and for NT compiler.
> 
> 1. This test case contains a number of VA C++ compiler extensions
> (_Optlink, _System, __stdcall, __cdecl, and _Pascal).  How does
> the parser handle these unusual keywords? 
> 
> (Note: These are typically used when compiling on Intel processors,
> hence the overlap with some Microsoft Visual C++ extensions.)

As before, if Acacia can't probe the compiler, it can't do anything for
these macros.  Acacia can't parse this file.