another core dump to be fixed before 1.4.5

[Eric Blake]

Just found this one:

$ m4 -tfoo
indir(`foo')
stdin:1: m4: INTERNAL ERROR: Bad symbol type in call_macro ()
Aborted (core dumped)

It turns out the hash table tracks macro names that must be traced once 
defined, but indir does not filter on whether the macro is already defined.  
I'll add a test case and patch this soon.

Further investigation turned up these additional differences between Solaris 
and GNU.  I doubt any of them are show-stoppers for 1.4.5, but I will probably 
be able to fix them anyways as part of fixing John's coredump about undefining 
a symbol while it is being used in macro expansion.  Of course, a fix includes 
adding a test case in m4.texinfo, so that we don't regress in the future.

$ /usr/ccs/bin/m4
traceon`'define(`foo',`1')foo
Trace(0): define(foo,1)
Trace(0): foo
1
^D
$ m4
traceon`'define(`foo',`1')foo
m4trace: -1- define
1
^D

Hmm - Solaris traceon is truly global, so new definitions are traced.  But GNU 
simply marks all existing macros as traced, which ignores new definitions.


$ /usr/ccs/bin/m4
define(`foo',`1')define(`bar',`2')traceon(`foo')

foo bar
Trace(0): foo
1 2
traceon

foo bar
Trace(0): foo
Trace(0): bar
1 2
traceoff
Trace(0): traceoff

foo bar
Trace(0): foo
1 2
^D
$ m4
define(`foo',`1')define(`bar',`2')traceon(`foo')

foo bar
m4trace: -1- foo
1 2
traceon

foo bar
m4trace: -1- foo
1 m4trace: -1- bar
2
traceoff
m4trace: -1- traceoff

foo bar
1 2
^D

Hmm - Solaris global traceon is independent of the macro traceon status, so a 
named trace remains in force regardless of the global trace status.  GNU m4 
does not have global trace status, so named traces are lost at global traceoff.


$ /usr/ccs/bin/m4
traceon(`bar')define(`bar',`1')bar
1
^D
$ m4
traceon(`bar')define(`bar',`1')bar
stdin:1: m4: Undefined name bar
1
^D
$ m4 -tbar
traceon(`bar')define(`bar',`1')bar
m4trace: -1- bar
1

Hmm - when requesting a trace by name, Solaris just ignores the request for 
undefined macros. GNU m4 warns if the macro is not in use.  But at startup, it 
reserves a slot in the hashtable at startup for undefined names mentioned by -
t, and the warning is avoided in that case.  Not very consistent.  When not 
worried about matching traditional behavior, either GNU should always warn 
about tracing an undefined macro; or better yet, always behave as though a 
currently undefined macro can later be defined with tracing already enabled, as 
though specified by -t.  When trying to be traditional, it should just be 
silent on unknown trace requests.

-- 
Eric Blake