cflow-1.1 doesn't find main

[Robert E. Michael]

    Last week I downloaded cflow-1.1.tar.gz, unpacked it, ran
configure, and then did make followed by make install on a
Sparc Ultra 1 running Solaris 9.  The compiler was gcc version 3.2.
There were no errors.
    Yet when I run it on quite a few of my own programs, the "main"
routine does not show up in the output.  A terse example is
attached.  When I run it on much larger examples, it gets a
segmentation fault.  What is going on?

Bob Michael


#include <stdio.h>

main(argc, argv)
int argc;
char *argv[];
{
        int fileidx;

        if (argc <= 1)
        {
                fprintf(stderr,"usage: sumweather <csvweatherfile> [<csvweatherfile> ...]\n");
                exit(1);
        }

        for (fileidx = 1; fileidx < argc; fileidx++)
        {
                printf("%s\n", argv[fileidx]);
        }

        exit(0);
}

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

[Sergey Poznyakoff]

Robert E. Michael <rmichael2@...> wrote:

>     Yet when I run it on quite a few of my own programs, the "main"
> routine does not show up in the output.  A terse example is
> attached.

It is a bug in cflow: it was confused by k&r function declarations.
Please find attached a patch that fixes it.

> When I run it on much larger examples, it gets a
> segmentation fault.  What is going on?

Possibly this is due to another bug, discovered yesterday.  I have sent
the corresponding patch to the list yesterday.  Just in case, I am
resending it with this message (see atachment 2.)

Please, inform me if it works for you.

Regards,
Sergey


Index: src/parser.c
===================================================================
RCS file: /cvsroot/cflow/cflow/src/parser.c,v
retrieving revision 1.35
diff -p -u -r1.35 parser.c
--- src/parser.c 15 Mar 2006 19:32:34 -0000 1.35
+++ src/parser.c 7 Sep 2006 15:17:06 -0000
@@ -30,13 +30,13 @@ typedef struct {
 void parse_declaration(Ident*, int);
 void parse_variable_declaration(Ident*, int);
 void parse_function_declaration(Ident*, int);
-void parse_dcl(Ident*);
+void parse_dcl(Ident*, int maybe_knr);
 void parse_knr_dcl(Ident*);
 void parse_typedef();
 void expression();
 void initializer_list();
 void func_body();
-void declare(Ident*);
+void declare(Ident*, int maybe_knr);
 void declare_type(Ident*);
 int dcl(Ident*);
 int parmdcl(Ident*);
@@ -540,7 +540,7 @@ parse_variable_declaration(Ident *ident,
   }
      }
  again:
-     parse_dcl(ident);
+     parse_dcl(ident, 0);
     
  select:    
      switch (tok.type) {
@@ -613,58 +613,7 @@ void
 parse_knr_dcl(Ident *ident)
 {
      ident->type_end = -1;
-     parse_dcl(ident);
-     if (strict_ansi)
-  return;
-    
-     switch (tok.type) {
-     case IDENTIFIER:
-     case TYPE:
-     case STRUCT:
-  if (ident->parmcnt >= 0) {
-       /* maybe K&R function definition */
-       int parmcnt, stop;
-       Stackpos sp, new_sp;
-       Ident id;
-      
-       mark(sp);
-       parmcnt = 0;
-      
-       for (stop = 0; !stop && parmcnt < ident->parmcnt;
-    nexttoken()) {
-    id.type_end = -1;
-    switch (tok.type) {
-    case LBRACE:
-    case LBRACE0:
- putback();
- stop = 1;
- break;
-    case TYPE:
-    case IDENTIFIER:
-    case STRUCT:
- putback();
- mark(new_sp);
- if (dcl(&id) == 0) {
-      parmcnt++;
-      if (tok.type == ',') {
-   do {
- tos = id.type_end; /* ouch! */
- restore(new_sp);
- dcl(&id);
-   } while (tok.type == ',');
-      } else if (tok.type != ';')
-   putback();
-      break;
- }
- /* else */
- /* FALLTHRU */
-    default:
- restore(sp);
- return;
-    }
-       }
-  }
-     }
+     parse_dcl(ident, !strict_ansi);    
 }
 
 void
@@ -717,7 +666,7 @@ parse_typedef()
 }
 
 void
-parse_dcl(Ident *ident)
+parse_dcl(Ident *ident, int maybe_knr)
 {
      ident->parmcnt = -1;
      ident->name = NULL;
@@ -725,7 +674,7 @@ parse_dcl(Ident *ident)
      dcl(ident);
      save_stack();
      if (ident->name)
-  declare(ident);
+  declare(ident, maybe_knr);
      else
   undo_save_stack();
 }
@@ -947,8 +896,61 @@ func_body()
      }
 }
 
+int
+get_knr_args(Ident *ident)
+{
+     int parmcnt, stop;
+     Stackpos sp, new_sp;
+     Ident id;
+
+     switch (tok.type) {
+     case IDENTIFIER:
+     case TYPE:
+     case STRUCT:
+  /* maybe K&R function definition */
+  
+  mark(sp);
+  parmcnt = 0;
+  
+  for (stop = 0; !stop && parmcnt < ident->parmcnt;
+       nexttoken()) {
+       id.type_end = -1;
+       switch (tok.type) {
+       case LBRACE:
+       case LBRACE0:
+    putback();
+    stop = 1;
+    break;
+       case TYPE:
+       case IDENTIFIER:
+       case STRUCT:
+    putback();
+    mark(new_sp);
+    if (dcl(&id) == 0) {
+ parmcnt++;
+ if (tok.type == ',') {
+      do {
+   tos = id.type_end; /* ouch! */
+   restore(new_sp);
+   dcl(&id);
+      } while (tok.type == ',');
+ } else if (tok.type != ';')
+      putback();
+ break;
+    }
+    /* else */
+    /* FALLTHRU */
+       default:
+    restore(sp);
+    return 1;
+       }
+  }
+     }
+     return 0;
+}
+
 void
-declare(Ident *ident)
+declare(Ident *ident, int maybe_knr)
 {
      Symbol *sp;
     
@@ -965,8 +967,10 @@ declare(Ident *ident)
   sp->arity = -1;
   return;
      }
-    
-     if ((ident->parmcnt >= 0 && !(tok.type == LBRACE || tok.type == LBRACE0))
+
+     if ((ident->parmcnt >= 0
+  && (!maybe_knr || get_knr_args(ident) == 0)
+  && !(tok.type == LBRACE || tok.type == LBRACE0 || tok.type == TYPE))
  || (ident->parmcnt < 0 && ident->storage == ExplicitExternStorage)) {
   undo_save_stack();
   /* add_external()?? */

Organization: Err, what do you mean?
To: <lfournie@...>
From: "Sergey Poznyakoff" <gray@...>
Date: Wed, 06 Sep 2006 18:26:32 +0300
Subject: Re: [Bug-cflow] seg. fault with 'cflow -ix^s ' options
X-Mailer: MH-E 7.84+cvs; GNU Mailutils 1.0; GNU Emacs 21.3.2
Cc: pjean@..., bug-cflow@...
Sender: bug-cflow-bounces+gray=mirddin.farlep.net@...

<lfournie@...> wrote:

> Just to repport that the last GNU cflow (1.1) raises a segmentation fault
> if used with following option on cflow 1.1 source code
>
> cflow -ix^s cflow-1.1/src/*.c

Thank you.  Here is the patch:

Index: src/symbol.c
===================================================================
RCS file: /cvsroot/cflow/cflow/src/symbol.c,v
retrieving revision 1.17
diff -p -u -r1.17 symbol.c
--- src/symbol.c 15 Mar 2006 19:33:01 -0000 1.17
+++ src/symbol.c 6 Sep 2006 15:25:45 -0000
@@ -107,7 +107,9 @@ unlink_symbol(struct table_entry *tp)
 static void
 delete_symbol(struct table_entry *tp)
 {
-     free(unlink_symbol(tp));
+     Symbol *s = unlink_symbol(tp);
+     if (s->ref_line == NULL) /* Symbol is not referenced */
+  free(s);
 }    
 
 static void cleanup_symbol_refs(Symbol *sym);


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

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

[Robert E. Michael]

Sergey,
    I got all the changes in and did make and make install without errors.
Now it properly does my little test program.  But it still gets sermentation
faults on lots of other programs.  Perhaps the best example is on src/c.c
in cflow itself (I know this is a flex generated file.  But cflow should not
core dump on it!).

Bob Michael

Sergey Poznyakoff wrote:

> Robert E. Michael <rmichael2@...> wrote:
>
> >     Yet when I run it on quite a few of my own programs, the "main"
> > routine does not show up in the output.  A terse example is
> > attached.
>
> It is a bug in cflow: it was confused by k&r function declarations.
> Please find attached a patch that fixes it.
>
> > When I run it on much larger examples, it gets a
> > segmentation fault.  What is going on?
>
> Possibly this is due to another bug, discovered yesterday.  I have sent
> the corresponding patch to the list yesterday.  Just in case, I am
> resending it with this message (see atachment 2.)
>
> Please, inform me if it works for you.
>
> Regards,
> Sergey

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

[Sergey Poznyakoff]

Robert E. Michael <rmichael2@...> wrote:

>     I got all the changes in and did make and make install without errors.
> Now it properly does my little test program.  But it still gets sermentation
> faults on lots of other programs.  Perhaps the best example is on src/c.c
> in cflow itself (I know this is a flex generated file.  But cflow should not
> core dump on it!).

Strange, it parses c.c without any problem on my box. It could be some
Solaris-specific issue. Unfortunately I do not have any Sparc box for
testing. Could you help me test it?

Regards,
Sergey


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

[Sergey Poznyakoff]

Hi Robert,

> I have not looked at the makefile yet, but is there an easy way to build
> a debug version with symbols so that I can use gdb to tell you where it
> is dying?

Yes, there is.  Configure it with --enable-debug switch, then run `make
clean' and `make'.

> I have never used gdb, and
> its command set might be vastly different from the dbx one.  So I may
> need some hints from you.

Sure.  Let's start with the following:

1. Run `gdb cflow'
2. On gdb prompt, type `run -ix^s c.c'
3. When it coredumps, type `where' and send me the output it produces.

This will give me sufficient info to decide on what to do next.

I'll be on line to attend your mails within the nearest four hours (my TZ
is 7 hours ahead of yours).

Regards,
Sergey


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

[Robert E. Michael]

Sergey,
    The output you requested is in the attached file.  I tried to print
several variables, but that did not work very well.  I also tried to
stop in the declare routine so that I could plant a stop right
before the "error_at_line" gets called.  But that did not work - it
did not stop.  I probably do not know the proper commands for
doing that in gdb.

Bob Michael

Sergey Poznyakoff wrote:

> Hi Robert,
>
> > I have not looked at the makefile yet, but is there an easy way to build
> > a debug version with symbols so that I can use gdb to tell you where it
> > is dying?
>
> Yes, there is.  Configure it with --enable-debug switch, then run `make
> clean' and `make'.
>
> > I have never used gdb, and
> > its command set might be vastly different from the dbx one.  So I may
> > need some hints from you.
>
> Sure.  Let's start with the following:
>
> 1. Run `gdb cflow'
> 2. On gdb prompt, type `run -ix^s c.c'
> 3. When it coredumps, type `where' and send me the output it produces.
>
> This will give me sufficient info to decide on what to do next.
>
> I'll be on line to attend your mails within the nearest four hours (my TZ
> is 7 hours ahead of yours).
>
> Regards,
> Sergey

GNU gdb 5.2.1
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "sparc-sun-solaris"...
(gdb) run -ix c.c
Starting program: /opt/sfw/cflow-1.1/src/cflow -ix c.c

Program received signal SIGSEGV, Segmentation fault.
0xff2b44e8 in strlen () from /usr/lib/libc.so.1
(gdb) where
#0  0xff2b44e8 in strlen () from /usr/lib/libc.so.1
#1  0xff306ac8 in _doprnt () from /usr/lib/libc.so.1
#2  0xff308498 in fprintf () from /usr/lib/libc.so.1
#3  0x00028584 in error_at_line (status=0, errnum=0, file_name=0x577c0 "c.c",
    line_number=1492, message=0x2f760 "%s/%d redefined") at error.c:275
#4  0x00018920 in declare (ident=0xffbff348, maybe_knr=0) at parser.c:986
#5  0x00017844 in parse_dcl (ident=0xffbff348, maybe_knr=0) at parser.c:677
#6  0x00017274 in parse_variable_declaration (ident=0xffbff348, parm=0)
    at parser.c:543
#7  0x000169f0 in parse_declaration (ident=0xffbff348, parm=0) at parser.c:370
#8  0x0001688c in yyparse () at parser.c:333
#9  0x000150f0 in main (argc=3, argv=0xffbff44c) at main.c:780
(gdb) print ident
$1 = {int ()} 0x1ca9c <ident>
(gdb) print ident->name
Attempt to extract a component of a value that is not s structure pointer
(gdb) print sp
No symbol "sp" in current context
(gdb) up
#1  0xff306ac8 in _doprnt () from /usr/lib/libc.so.1
(gdb) up
#2  0xff308498 in fprintf () from /usr/lib/libc.so.1
(gdb) up
#3  0x00028584 in error_at_line (status=0, errnum=0, file_name=0x577c0 "c.c",
    line_number=1492, message=0x2f760 "%s/%d redefined") at error.c:275
275 fprintf (stderr, "%s:", program_name);
(gdb) print ident
$2 = {int ()} 0x1ca9c <ident>
(gdb) q
The program is running.  Exit anyway? (y or n)

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

[Robert E. Michael]

Sergey,
    I read some more of the info for gdb and learned how to apply
breakpoints.  By doing so, I traced the segmentation fault to line
275 in the lib/error.c file.  It is trying to print program_name,
which does not exist (gdb complains when I do a print program_name).
However, gdb prints 0x0 for program_invocation_name.  So there
seems to be something wrong with the definition of _LIBC, such
that it allows the alias of program_name to program_invocation_name,
but somehow program_invocation_name is never set.  Perhaps there
is a mistake in the Solaris implementation of LIBC such that
program_invocation_name is never set.  Perhaps line 270 or
error.c should be #ifdef _LIBC rather than #if _LIBC?

    If I place "if (program_name != NULL)" before line 275 and
recompile, then cflow runs and generates dozens of "redefined"
error messages.  I am not sure I understand enough about the
details of how cflow handles compiler variables like __STDC__
and __cplusplus.  Depending on what it does, there could be
multiple definitions in c.c, which is heavily laced with #ifdef
statements.  Do you get many "redefined" messages from your
run of cflow on c.c?

Bob Michael



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

[Sergey Poznyakoff]

Robert E. Michael <rmichael2@...> wrote:

>     The output you requested is in the attached file.

Thank you.  Please add the following line to your config.h:

#define program_name program_invocation_name

and recompile the program.  Does it fix the problem?

Regards,
Sergey




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

[Sergey Poznyakoff]

Robert E. Michael <rmichael2@...> wrote:

> So there
> seems to be something wrong with the definition of _LIBC, such
> that it allows the alias of program_name to program_invocation_name,
> but somehow program_invocation_name is never set.

In fact, _LIBC is never defined, so this part of code is not
compiled.  What happens is that program_invocation_name *is* set
(lib/argp-pin.c), whereas program_name is not.  The define you are
talking about was designed to compensate for it in case of glibc code,
but it has no force otherwise.  That is why placing `#define
program_name program_invocation_name' in your config.h should fix it.
Actually, that should have been done by configure, but somehow I
forgotten to make it there:)

>     If I place "if (program_name != NULL)" before line 275 and
> recompile, then cflow runs and generates dozens of "redefined"
> error messages.  I am not sure I understand enough about the
> details of how cflow handles compiler variables like __STDC__
> and __cplusplus.

Yes, this is described in detail in the documentation (chapter 8,
"Running Preprocessor".  The online copy available at
http://www.gnu.org/software/cflow/manual).  Run it with preprocessor and
the messages will go away.  E.g.:

$ cd cflow-1.1/src
$ cflow -I.. -I. c.c

Regards,
Sergey
 


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

[Robert E. Michael]

Sergey,

    #define  program_name  program_invocation_name
is already in my config.h file.  That is why when I stop at line 275
and try to print program_name, gdb replies:
    No symbol "program_name" in current context
But when I print program_invocation_name, gdb replies:
    $10 = 0x0
So program_invocation_name is defined, but it is set to NULL,
rather than the actual program name or the value of argv[0].
So, no, it does not fix the core dump from cflow.  In fact, as far
as I can tell (in argp-parse.c line 947), program_invocation_name
is only set if I set it when I execute cflow, as in:
    cflow --program-name  cflow  c.c
That works, and I get the name I supply printed in the error
messages.

    There is another curiosity that I am having trouble explaining.
In the nohup output from ./configure --enable-debug, I find the
following statements:
    checking whether program_invocation_name is declared... no
    checking whether program_invocation_short_name is declared... no
But in the config.h file,
HAVE_DECL_PROGRAM_INVOCATION_NAME is defined to 1,
while HAVE_DECL_PROGRAM_INVOCATION_SHORT_NAME
is defined to 0.  When I write a two line program that has the statements:
    extern char *program_invocation_name;
    printf(%s\n",program_invocation_name);
and compile it with gcc, the linker complains that
"program_invocation_name is undefined.   Thus the output from the
configure script is correct, but the config.h variable
HAVE_DECL_PROGRAM_INVOCATION_NAME is set anyway.
Perhaps that is because program_invocation_name is always defined
in pin.c.  But shouldn't there be some code somewhere that sets
program_invocation_name to the contents of argv[0]?  Otherwise,
a user who does not supply a command line --program-name,
and whose C file or files has an error will get a core dump rather
than an error message.  There is some code in argp-parse.c between
lines 556 and 569 that tries to look at argv[0], but it does not set
program_invocation_name.  Instead it sets parser->state.name,
which is not used anywhere.  And there is a comment around line
1689 in argp-help.c that suggests that something is broken in
this whole mess about getting a printable program name.  Since
always including the variable "program_invocation_name" is
already a kludge, then its definition in pin.c should be:
    char *program_invocation_name = "cflow";
That way, error messages will not cause a segmentation fault,
and the user can still supply a program name with the command
line --program-name option.

Bob Michael

Sergey Poznyakoff wrote:

> Robert E. Michael <rmichael2@...> wrote:
>
> > So there
> > seems to be something wrong with the definition of _LIBC, such
> > that it allows the alias of program_name to program_invocation_name,
> > but somehow program_invocation_name is never set.
>
> In fact, _LIBC is never defined, so this part of code is not
> compiled.  What happens is that program_invocation_name *is* set
> (lib/argp-pin.c), whereas program_name is not.  The define you are
> talking about was designed to compensate for it in case of glibc code,
> but it has no force otherwise.  That is why placing `#define
> program_name program_invocation_name' in your config.h should fix it.
> Actually, that should have been done by configure, but somehow I
> forgotten to make it there:)
>
> >     If I place "if (program_name != NULL)" before line 275 and
> > recompile, then cflow runs and generates dozens of "redefined"
> > error messages.  I am not sure I understand enough about the
> > details of how cflow handles compiler variables like __STDC__
> > and __cplusplus.
>
> Yes, this is described in detail in the documentation (chapter 8,
> "Running Preprocessor".  The online copy available at
> http://www.gnu.org/software/cflow/manual).  Run it with preprocessor and
> the messages will go away.  E.g.:
>
> $ cd cflow-1.1/src
> $ cflow -I.. -I. c.c
>
> Regards,
> Sergey
>

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

[Sergey Poznyakoff]

Robert E. Michael <rmichael2@...> wrote:

> So program_invocation_name is defined, but it is set to NULL,

Yes, you are right. Please try the following snapshot:

     ftp://download.gnu.org.ua/pub/alpha/cflow/cflow-1.1-20060910.tar.bz2

Regards,
Sergey
     


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

[Robert E. Michael]

Sergey,
    The alpha 20060910 works a little better in that it prints error
messages without me having to supply a --program-name.  But
it still gets a segmentation fault on the c.c file.  The fault is at line
276 in output.c.  The value of sym is 0x318, and trying to print
sym->type gets a message from gdb "cannot access memory at
address 0x31c.
    I did a compare of all the files in the src directory and found that
the patches you previously sent for symbol.c and parser.c are not
present in the alpha source.  I will try putting them back in and see
if that fixes everything.

Bob Michael

Sergey Poznyakoff wrote:

> Robert E. Michael <rmichael2@...> wrote:
>
> > So program_invocation_name is defined, but it is set to NULL,
>
> Yes, you are right. Please try the following snapshot:
>
>      ftp://download.gnu.org.ua/pub/alpha/cflow/cflow-1.1-20060910.tar.bz2
>
> Regards,
> Sergey
>

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

[Robert E. Michael]

Sergey,

    Reinstalling the patches to parser.c and symbol.c does seem
to fix the segmentation fault.
    I did notice that the printed error message now has the long
(i.e., full path) invocation name, rather than the short name
one usually expects.  But perhaps that is what is expected of
gnu tools.

    I have read the documentation you pointed me to because I
am looking for a way to exclude certain functions from cflow
listings.  In particular, for a large system that I am trying to learn,
it would be of great help if I had a convenient way to suppress the
common library routines such as "strchr" (and its relatives), and
maybe even some common IO routines line "fprintf".  That way
I can concentrate on the unique structure of that system, instead
of being bogged down by having to scan past lots of function
names which do not help me understand the new system.  I read about
the --include=spec command line switch, but it doesn't look like
that really does what I want.  Is there a way?

Bob Michael



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

[Sergey Poznyakoff]

Robert E. Michael <rmichael2@...> wrote:

>     I did notice that the printed error message now has the long
> (i.e., full path) invocation name, rather than the short name
> one usually expects.  But perhaps that is what is expected of
> gnu tools.

Yes, the general principle is: the tool identifies itself with the name
under which it was invoked.  Compare (on GNU system):

  $ mv foobar x
  mv: cannot stat `foobar': No such file or directory
  $ /usr/bin/mv foobar x
  /usr/bin/mv: cannot stat `foobar': No such file or directory

> it would be of great help if I had a convenient way to suppress the
> common library routines such as "strchr" (and its relatives), and
> maybe even some common IO routines line "fprintf".  That way
> I can concentrate on the unique structure of that system, instead
> of being bogged down by having to scan past lots of function
> names which do not help me understand the new system.

Aha, yes, I see.  Currently there is no easy way to achieve this, but it
should not be hard to implement. Right from the top of my head I'd
propose an option telling cflow to display only those symbols
that are defined anywhere in the sources it is given in the command
line. Will such an option help?

Regards,
Sergey


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

[Sergey Poznyakoff]

Sergey Poznyakoff <gray@...> wrote:

> Right from the top of my head I'd
> propose an option telling cflow to display only those symbols
> that are defined anywhere in the sources it is given in the command
> line. Will such an option help?

As a test implementation of this thought, please try the enclosed
patch.  It adds the new symbol class 'u', which stands for 'undefined
symbols'.  Running `cflow -i^u' will omit from the output all symbols,
not defined in the sources.

Regards,
Sergey

Index: src/main.c
===================================================================
RCS file: /cvsroot/cflow/cflow/src/main.c,v
retrieving revision 1.38
diff -p -u -r1.38 main.c
--- src/main.c 11 Sep 2006 18:28:51 -0000 1.38
+++ src/main.c 11 Sep 2006 20:11:05 -0000
@@ -214,11 +214,13 @@ int omit_symbol_names_option; /* Omit sy
 #define SM_STATIC      0x0004
 #define SM_UNDERSCORE  0x0008
 #define SM_TYPEDEF     0x0010
+#define SM_UNDEFINED   0x0020
 
 #define CHAR_TO_SM(c) ((c)=='x' ? SM_DATA : \
                         (c)=='_' ? SM_UNDERSCORE : \
                          (c)=='s' ? SM_STATIC : \
-                          (c)=='t' ? SM_TYPEDEF : 0)
+                          (c)=='t' ? SM_TYPEDEF : \
+                           (c)=='u' ? SM_UNDEFINED : 0)
 #define SYMBOL_INCLUDE(c) (symbol_map |= CHAR_TO_SM(c))
 #define SYMBOL_EXCLUDE(c) (symbol_map &= ~CHAR_TO_SM(c))
 int symbol_map;  /* A bitmap of symbols included in the graph. */
@@ -593,6 +595,7 @@ parse_opt (int key, char *arg, struct ar
        case '_':
        case 's':
        case 't':
+       case 'u':
     if (num)
  SYMBOL_INCLUDE(*arg);
     else
@@ -710,6 +713,10 @@ include_symbol(Symbol *sym)
        type |= SM_DATA;
   else if (sym->arity >= 0)
        type |= SM_FUNCTIONS;
+
+  if (!sym->source)
+       type |= SM_UNDEFINED;
+  
      } else if (sym->type == SymToken) {
   if (sym->token_type == TYPE && sym->source)
        type |= SM_TYPEDEF;
@@ -755,7 +762,7 @@ main(int argc, char **argv)
      register_output("gnu", gnu_output_handler, NULL);
      register_output("posix", posix_output_handler, NULL);
 
-     symbol_map = SM_FUNCTIONS|SM_STATIC;
+     symbol_map = SM_FUNCTIONS|SM_STATIC|SM_UNDEFINED;
 
      if (getenv("POSIXLY_CORRECT")) {
   if (select_output_driver("posix"))


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