I tried the same with another macro instead of the one with empty name and, as you said, traceon does not trace the macros expanded through indir so yeah, I agree with you. I just tried with the empty macro and didn't think too much about it.
Regarding the development of a patch, I think I pass. However, I think it would be a good idea to have this behaviour documented in the manual in the sections where the manual explains the usage of traceon( https://www.gnu.org/software/m4/manual/m4.html#Trace) and indir( https://www.gnu.org/software/m4/manual/m4.html#Indir), respectively. On Tue, 26 Oct 2021 at 18:40, Eric Blake <ebl...@redhat.com> wrote: > On Tue, Oct 26, 2021 at 03:02:31AM +0200, 4dr14n31t0r Th3 G4m3r wrote: > > This m4 script does not show the trace for the macro whose name is the > > empty string: > > > > changequote([,]) > > define([],[Hello world]) > > traceon([]) > > indir([]) > > There's nothing special about the macro with the empty name. traceon > does not trigger tracing of ANY macro invoked through indir(), because > the code only traces the directly-invoked macro (in this case, indir). > > changequote([,])dnl > define([foo],[bar])dnl > traceon([foo])dnl > foo > m4trace: -1- foo > bar > indir([foo]) > bar > > What you can do, however, is 'traceon([indir])' to see ALL cases where > a macro was indirectly invoked, and then post-process that list to > find out where the particular macro you care about was invoked; or you > can use 'traceon' without arguments to trace every macro call. > Therefore, I don't think this is a bug, per se. But as tracing is a > debugging aid, and since indir is already a GNU extension, it is not > too hard to persuade me that it is not a violation of the POSIX > requirements on 'traceon' to also trace cases where a macro is > indirectly invoked as a quality-of-implementation improvement (at the > expense of now seeing two traces rather than one for each indirect > macro expansion), rather than the current status quo of requiring the > user to manually trace indir. > > Would you like to try your hand at writing a patch? It seems like > copying the logic using 'bool traced' around call_macro() in the > function src/macro.c:expand_macro() to also occur in > src/builtin.c:m4_indir() would do the trick, although a complete patch > would also want to add testsuite coverage (by documenting the feature > in m4.texi) and touch NEWS. It would probably be non-trivial enough > to require copyright assignment. [I ask if you're willing, because my > current time for m4 work has been fairly limited - I'm already behind > my desired schedule on releasing m4 1.4.20 to fix the 'format' > regression introduced in 1.4.19 in non-C locales] > > -- > Eric Blake, Principal Software Engineer > Red Hat, Inc. +1-919-301-3266 > Virtualization: qemu.org | libvirt.org > >
