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: Eric Blake
Subject: Re: traceon does not work with a macro whose name is the empty string
Date: Tue, 26 Oct 2021 11:39:58 -0500
User-agent: NeoMutt/20211022-9-8e6511

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]