Some programs have parts of them compiled under conditional preprocessor directives. Consider the following example:
erase_file
occurs three times
within the file.
However, because CScout preprocesses the file following the
C preprocessor semantics, it will typically match only two instances.
In some cases you can get around this problem by defining macros that will
ensure that all code inside conditional directives gets processed.
In other cases this will result in errors (e.g. a duplicate macro definition
in the above example).
In such cases you can include in your workspace the same project multiple
times, each time with a different set of defined macros.
workspace example { project idtest { define DEBUG 1 define TEST 1 file idtest.c util.c } project idtest2 { define NDEBUG 1 define PRODUCTION file idtest.c util.c }
Consider the following example:
id
instance should
also change the other three instances.
However, CScout will not associate the member of
s3
with the identifier appearing in the getid
macro or the
s1
or s2
structures,
because there is no getid
macro invocation to link them together.
If e.g. id
is replaced with val
the program will compile and function correctly,
but when one tries to access the c
struture's member
in the future using getid
an error will result.
We employ a heuristic classifying all instances of an undefined macro
as being the same identifier.
Thus in the following sequence foo
will match all
three macro instances:
In addition, the analysis of functions can be confused by the following situations.
Finally, because function argument refactoring works at a higher level thann simple identifiers, the following limitations hold.
Contents | « Previous Next (Error Messages) » |