On Mon, Apr 07, 2025 at 01:37:10PM -0500, Eric Blake wrote:
> On Mon, Apr 07, 2025 at 12:46:11PM -0500, Eric Blake wrote:
> > And relying on a configure-time test of what m4 supports on the
> > packager's machine is not necessarily going to work when autoconf is
> > run on a developer's machine with a different version of m4. Which in
> > turn implies that it is desirable to be able to probe at runtime what
> > is supported, rather than being limited to a command-line switch. But
> > while it is easy to write a runtime probe on whether "regexp([{],
> > [\{1\}]) results in -1 (old m4, ergo \{ is a literal) or 0 (m4 that
> > has enabled repetition operator semantics),
>
> Correcting myself: the above would return -1 regardless of whether \{
> is literal or repetition (since a repetition is no good without an
> earlier sequence to repeat). If you want probe a -1 or 0 value as a
> witness of regex flavor, then the haystack and needle have to be
> something a bit smarter. As in: regexp([{{], [.\{1\}]) which returns
> -1 when \{ is literal and 0 when it is a repetition.
Adding some more weirdness to be aware of:
I've been playing with the FreeBSD 14 build of m4, which has 'm4 -g'
that tries to be GNU-alike (it's not perfect, but close). But among
other things:
# m4 -g
regexp({,\{)
0
regexp({,{)
m4: stdin at line 2: regular expression error in {: repetition-operator operand
invalid.
#
Urgh - BSD has tried hard to make their m4 be a drop-in replacement
enough that autoconf will use it instead of mandating GNU m4, but not
only is the hard exit (rather than a warning) undesirable, the fact
that they picked { rather than \{ for repetition in the emacs-like
syntax is backwards. (It's easy enough to patch autoconf's configure
to weed out broken m4 like this, at which point it will be an arms
race until BSD changes their m4 to comply again...)
--
Eric Blake, Principal Software Engineer
Red Hat, Inc.
Virtualization: qemu.org | libguestfs.org
