Re: BSD cflow available

On, Thu Jan 17, 2008, Ed Schouten wrote:

> Hello Marcus,
> 
[...]
 
> I just tried cgraph to see how it works, I've never used cflow before (I
> didn't even know it was part of POSIX). I don't know if this is required
> by the standards, but here it goes:
> 
> When I create 2 C files:
> 
> ~~~~~~~~~~~~~~~~~~
> a.c:
> 
> void a(void)
> {
> 	b();
> }
> ~~~~~~~~~~~~~~~~~~
> 
> ~~~~~~~~~~~~~~~~~~
> b.c:
> 
> void b(void)
> {
> }
> ~~~~~~~~~~~~~~~~~~
> 
> Two very simple C files with a function call that connects the objects
> together. When I run cgraph, I get this:
> 
> | 1 a: void(), <a.c 1>
> | 2   b: <>
> | 1 b: void(), <b.c 1>
> 
> Isn't the application supposed to resolve b as well? cflow looks like a
> useful utility. Hope to see it get integrated. :-)

No, it should not resolve b here. In contrast to the POSIX requirements
this implementation accepts multiple source code files at once in order
to ease the generation of multiple graphs at once. Technically those are
built one after each other, without knowing about the contents of the
previously parsed file.

The problem with your expectation lies within the nature of C code
itself (you surely know that): How should the parser know that b is the
correct function to be referenced by a()? It can't know and letting it
guess this can quickly lead to unwanted, wrong results in the parsing
and output tree. Imagine two static functions, both with the same name
in each C file. Or a.c is linked to a library, which also defines b()
and thus is not related to b.c itself.

As cflow - in my opinion - is a useful tool to get a better overview
about the control flow in (possibly unknown) source code, being "better
safe than sorry" would be the best way to go here, I think.

Your expectation however shows that both, the output for multiple
files, and the man pages should reflect that :-).

Regards
Marcus