bug-m4
[Top][All Lists]
Advanced

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

Re: traceon does not work with a macro whose name is the empty string


From: 4dr14n31t0r Th3 G4m3r
Subject: Re: traceon does not work with a macro whose name is the empty string
Date: Tue, 26 Oct 2021 22:38:23 +0200

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 <eblake@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


reply via email to

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