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 _______________________________________________ Bug-m4 mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-m4
