bug-cflow
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [bug-cflow] Help, please! I want to analyse ALL functions in a set o


From: Alan Mackenzie
Subject: Re: [bug-cflow] Help, please! I want to analyse ALL functions in a set of C files.
Date: Sun, 10 Mar 2019 13:42:40 +0000
User-agent: Mutt/1.10.1 (2018-07-13)

Hello, Sergey.

First of all, apologies for the long delay in answering.  I got caught
up in two difficult Emacs bugs which seemed urgent, and both took longer
to fix than expected.

On Sun, Feb 10, 2019 at 20:24:05 +0200, Sergey Poznyakoff wrote:
> Hi Alan,

> I have uploaded to alpha.gnu.org cflow version 1.5.90 [1].

> This version implements the new option "--all", which instructs cflow
> to output separate flow graphs for each top-level function defined in
> the program. The "top-level" here means a function not reachable from
> any other function in the program (functions reachable from another ones
> will appear in the output anyway).

> If the code does contain the "main" function, the graph for that
> function will appear first, followed by graphs for the rest of
> functions.

> The graphs are ordered alphabetically by their top-level function name.

> The new option "--no-main" deprives the main function of its special
> status, forcing its graph to appear among others in the alphabetical
> order.

> This version also includes a set of improvements in the C parser.

> I'd appreciate any feedback.

It works.  It works well.  :-)

There's another unrelated problem I'm having with cflow, and I was
slightly hesitant to mention it.  But....

If a function's name is in parentheses, cflow doesn't seem to detect it.
For example, in Emacs's src/lisp.h we have:

    INLINE bool
    (NILP) (Lisp_Object x)
    {
      return lisp_h_NILP (x);
    }

.  INLINE is a macro expanding to something like __inline__, bool is the
function's type, NILP is its name, and (Lisp_Object x) is its parameter
list.  The reason for NILP being in parens is to prevent it being
expanded as a macro, since there is sometimes a #define NILP active in
the source.  (Yes, I know, it seems strange programming, but I didn't
write it.)

Would it be possible to amend cflow to recognise such syntax?  I know
that it's not common in practice, and that it's somewhat tricky (having
recently amended Emacs CC Mode to handle such declarations), but it
seems to be a gap in cflow.

> Best regards,
> Sergey

> [1] http://alpha.gnu.org/gnu/cflow/cflow-1.5.90.tar.gz

-- 
Alan Mackenzie (Nuremberg, Germany).



reply via email to

[Prev in Thread] Current Thread [Next in Thread]