I'm delighted to receive the progress report, and especially the
mention of tail recursion. Am I right in guessing that all tail calls
will benefit, so that n levels of tail recursion will use O(1) stack
space rather than O(n)?
Doug McIlroy
On Thu, Apr 3, 2025 at 3:37 PM Eric Blake <ebl...@redhat.com> wrote:
>
> On Mon, Mar 31, 2025 at 05:35:36PM -0400, Dennis Clarke via Bug reports for
> the GNU m4 macro processor wrote:
> >
> > This has already been reported and it is known that the m4-1.4.19 will
> > no longer build out of the box on a recent Linux machine. Certainly not
> > with any recent GCC and perfectly sane configuration options.
>
> Indeed - but I'm about to release 1.4.20, since I just barely proposed
> a bug-fix[1] for eval ("eval(1||1/0)" short-circuits, but
> "eval(1||(1/0))" fails, and this inconsistency has been present,
> unnoticed, since 1.4.8b in 2007). So that release should fix the
> current problems with 1.4.19 failing to build.
>
> [1] https://lists.gnu.org/archive/html/m4-patches/2025-04/msg00003.html
>
> >
> > Perhaps this mail list and the bug-m4 maillist are dead? This has been
> > reported before :
> >
> > https://lists.gnu.org/archive/html/m4-discuss/2025-02/msg00000.html
>
> Not quite dead, but I have very little free time to spend on m4, and
> it is a relatively stable project with few other volunteers. (Alas,
> although I'm using a Red Hat email, m4 is far enough afield from my
> current assignments of Red Hat that I do not get to spend company time
> on m4 maintenance - it has to be my personal time, and my life
> situation is much different now than it was 15 years ago)
>
> >
> > At the very least a beta for 1.6 could be tested.
>
> Here's my problem with that idea: branch-1.6 is in worse shape than
> branch-1.4; its last commit was in 2010, and it is missing a NUMBER of
> patches that were added to branch-1.4 as bug fixes, which will need to
> be forward-ported. Keep in mind, back in 2010, I was still relatively
> new to git, and did not have as good an idea on how best to insist on
> upstream first and backports to stable branches the way I do now; so
> this is the opposite problem of what most distros have on
> cherry-picking backport candidates from upstream. Which means the
> more patches land in branch-1.4 (such as my fix to eval
> short-circuiting), the more work that will be required cherry-picking
> those into branch-1.6 before it will be ready for a beta release.
>
> I would love some assistance in the effort, even if it is as simple as
> curating a list of ALL commits to branch-1.4 and branch-1.6 since the
> two REALLY diverged (warning: back then, I was not using 'git
> cherry-pick -x' to identify when a patch was applied to one branch
> after appearing on another; and order of patches applied differs
> between the branch, so it is not just a linear effort). A possible
> starting point might be commits around Nov 2007; commit ac884556
> titled "Stage 1:..." was the start of my efforts to implement a MUCH
> faster parser for m4 1.6; or maybe the search needs to go back even
> further.
>
> As to the patches named "Stage X:", there's another back-story: 15
> years ago, I played with an experiment to make the following faster:
>
> $ m4 <<EOF
> changequote([,])define([process])dnl
> define([foo], [ifelse([\$1], , , [process([\$1])\$0(shift(\$@))])])dnl
> foo($(seq -s, 5000))
> EOF
>
> Currently, this has quadratic behavior (on my laptop, running that
> with 5000 arguments takes 1.7s, running it with 10000 takes 6.3s;
> doubling the parameter list size quadruples the runtime). In short,
> although the m4 parser is only expanding foo 5000 times, it is parsing
> approximately 5000*2500 parameters among those 5000 calls, and the
> parse-time is non-trivial. But in an ideal world (and in my
> experimental branch), m4 _should_ be able to process that type of tail
> recursion in linear time - by special-casing $@ and friends in macro
> expansion to be a reference to (a subset of) the incoming parameters,
> rather than copying into a new string (another way of looking at it:
> the work was teaching the m4 scanner engine to behave more like
> preadv() with the ability to join together input from disparate
> sources, rather than it's current behavior of having to copy
> everything into an obstack so that the scanner engine can then read()
> one byte at a time). I had code that was almost working for that
> goal, still visible at the argv_ref branch [2], which was a series of
> at least 34 "Stages" of patches that would be needed, but got stumped
> near the end on how do reference counting to not leak memory. But the
> experiment was running in parallel with other development, so porting
> it to branch-1.6 was non-trivial, and there I only got to Stage 29.
>
> >
> > triton$ git remote show origin
> > * remote origin
> > Fetch URL: http://git.savannah.gnu.org/r/m4.git
> > Push URL: http://git.savannah.gnu.org/r/m4.git
> > HEAD branch: master
> > Remote branches:
> > argv_ref tracked
>
> [2] THIS is the branch that I would love to see finished and folded
> into branch-1.6.
>
> > branch-1.4 tracked
> > branch-1.6 tracked
> > branch-2.0 tracked
> > include-dso tracked
> > master tracked
> > stackovf tracked
>
> >
> > There are plenty of things changing but I do not see where the linkage
> > problem is fixed in the git repo.
>
> Ideally, the linkage problem should have been fixed by upgrading to
> more recent gnulib. If it is still broken on the tip of branch-1.4,
> that is something that will need to be fixed before 1.4.20 is
> released. I haven't hit a libsigsegv link failure on my development
> machine, but part of the release process is trying to build elsewhere.
>
> --
> Eric Blake, Principal Software Engineer
> Red Hat, Inc.
> Virtualization: qemu.org | libguestfs.org
>
>
