Improper parsing of statics

[jds-2]

Some parts of this message have been removed. Learn more about Nabble's security policy.

Hi;

 

I'm finishing up a port of cflow to Windows, and noticed a parsing problem.  This appears to be a general parsing problem rather than a Windows-specific issue.

 

If I parse multiple files having static data members with the same name, cflow improperly reports redefinition of the static member:

 

In multi1.c:

 

    static int stat = 1;

    ...

 

In multi2.c:

 

    static int stat = 10;

    ...

 

cflow 1.0 reports this as multiple definition of the same variable.  Since these are static to the different files, they are not the same variable and should be recognized as distinct.  Further, if a function in multi1.c uses the variable 'stat', cflow will be attributed to the most recently parsed file rather than it's own static variable.  The same problem occurs for same-name static variables declared in functions.

 

If you want me to send in a patch, please let me know.

 

Thanks,

Jerry

_______________________________________________
Bug-cflow mailing list
Bug-cflow@...
http://lists.gnu.org/mailman/listinfo/bug-cflow

[jds-2]

"Sergey Poznyakoff" <gray@...> wrote:

>> If I parse multiple files having static data members with the same
>> name, cflow improperly reports redefinition of the static member:
>
> It is intended, since by default cflow processes both global and static
> data. If you wish to avoid it, exclude statics using -i^s option:
>
>   cflow -i^s file.c file2.c
>
> You will find a detailed discussion of symbol inclusion/exclusion
> policies in the documentation.

Yes, of course statics are included.  The problem is that cflow does not
properly keep track of scoping and visibility of identifiers.  As a result,
it (1) reports as redefinitions declarations that are not and (2) reports
the wrong location of declaration of such identifiers.

This may be a clearer example:

 static int i = 0;

 int foo(void)
 {
    static int i =10;
    return i;
}

int main()
{
   printf("file static = %d, local static = %d", i, foo());
   return 0;
}


Here's what < cflow -ix temp.c > reports:

(null):temp.c:5: i/-1 redefined
(null):temp.c:1: this is the place of previous definition
main() <int main () at temp.c:9>:
    printf()
    i <int i at temp.c:5>
    foo() <int foo (void) at temp.c:3>:
        i <int i at temp.c:5>


The redefinition report in the 1st & 2nd lines is a bug.  There is no
redefinition of i.  The 2 instances of i are in different scopes and are
different variables.   The 5th line also contains a bug.  The i that main()
references is defined on line 1 of the source, not line 5.

The same problems exist when:

1. statics with the same name are defined in separate files (my original
example)
2. a static in 1 file has the same name as a global in another file
3. variables are declared at file scope in different files

Now, adding scoping to cflow does not appear trivial.  The symbol table does
not appear to have any sense of scoping - symbols are added and looked up by
name only.  One would need to keep track of file and function scope for
statics, and take these into account in lookups by the parser.  The parser
would also need to keep track of  whether a global defined in another file
is actually brought into scope with an 'extern' declaration.

Have I misunderstood something?  I'd appreciate your thoughts.

Thanks again,
Jerry




_______________________________________________
Bug-cflow mailing list
Bug-cflow@...
http://lists.gnu.org/mailman/listinfo/bug-cflow

[Sergey Poznyakoff]

jds <jds.2005@...> wrote:

> If I parse multiple files having static data members with the same
> name, cflow improperly reports redefinition of the static member:

It is intended, since by default cflow processes both global and static
data. If you wish to avoid it, exclude statics using -i^s option:

   cflow -i^s file.c file2.c

You will find a detailed discussion of symbol inclusion/exclusion
policies in the documentation.

Regards,
Sergey


_______________________________________________
Bug-cflow mailing list
Bug-cflow@...
http://lists.gnu.org/mailman/listinfo/bug-cflow