How many times have you been working in a project, and asked the question
"where are all the places this global symbol is referenced?"

CGS tries to make answering this question a lot easier. It will show
function names and line numbers where global symbols are referenced.

Use CGS with no arguments to get command syntax.


To avoid having to implement a full C parser, CGS does have some limitations:

It assumes the source file(s) are error free (will compile without error).

It keeps track of '{}', '()' and '[]' levels. Anything at {}, () and [] level
0 is assumed to be global. Any use of a symbol at {} level 1+ is assumed to be
a reference. When {} level drops to zero, () and [] are also reset.

It does NOT follow C definition syntax. It treats the first global occurance
of a symbol as the definition of that symbol.

It does not detect or avoid local symbol references. If a local symbol has
the same name as a requested global symbol name, references to the local
symbol will be reported (fortunately this will happen only in the function
containing the conflicting local symbol).

It completely ignores anything past '#' on a line (preprocessor directives).
This means it does not do macro processing, will not detect references
"disguised" in macros, and will not detect/ignore inactive sections dur to
proprocessor conditionals. Note that it IS possible to corrupt visible
{}, () or [] nesting with the preprocessor which will interfere with CGS.
One way to resolve these issues it to run CGS on source code after it has been
preprocessod.

Dispite these limitations, I find CGS to be quite useful in practice, and
sure beats spending time searching through source code with an editor.
(Especially true if like me you tend to first comment out old function
references while testing changes)

Dave Dunfield   -   https://dunfield.themindfactory.com
