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
