Re: FYI: 13-gary-remove-redundant-traced-field.patch

[Gary V. Vaughan]

On Mon, Sep 17, 2001 at 04:45:03PM +0200, Akim Demaille wrote:
> >>>>> "Gary" == Gary V Vaughan <address@hidden> writes:
> 
> Gary> I'll look at this properly after the weekend when my chapter is
> Gary> done.  In the mean time, do you think that there is a genuine
> Gary> need to track the traced flag on each `struct m4_token_data'
> Gary> *and* each symbol name?
> 
> Well, I reversed the patch we are debating about, and nothing changes,
> it's coming from another one.

Indeed.  The oldest m4 I have to hand is m4-1.4o, which also has the
bug you describe :-(

> I definitely understand your point, but at the origin that was the
> guarantee that you could follow a builtin even if renamed (define +
> defn).

This is the same as having the trace bit attached to `struct
m4_token_data'...

> Today, I am more and more convinced that what would be really clean is
> simply a list of macros to be traced, and each time a macro is
> defined, we look at this list.

Ugh.  That sounds like a lot of unnecessary duplication in the
internal data, not to metion moving back towards keeping multiple
structures in synch.

> I.e., if I `m4 -t foo', then, what ever the number of define and
> undefine of foo, all invocation of the macro should be traced.
> 
> Up to now, only the invocations before the first undefine are traced.
> This is really what I'm looking for, and it is also what I consider as
> the sanest semantics for traces.

You are saying that you are looking for the behaviour in the `I.e., if
I...' paragraph, right?  This means that we store the flag against
whichever m4_token_data is stored in the named symbol when traceon is
invoked, and can be turned off by traceoff with the name of some
symbol that currently holds that m4_token_data.   I think there is one
small wrinkle in this approach, in that the command line trace
parameters will need to be stored for application a the end of command
line processing... but we already do that with some flags anyway so I
don't think that is too onerous.

Cheers,
        Gary.
-- 
  ())_. Gary V. Vaughan     gary@(oranda.demon.co.uk|gnu.org)
  ( '/  Research Scientist  http://www.oranda.demon.co.uk       ,_())____
  / )=  GNU Hacker          http://www.gnu.org/software/libtool  \'      `&
`(_~)_  Tech' Author        http://sources.redhat.com/autobook   =`---d__/