Re: Compiled gnu-m4 failed

[Eric Blake]

On Tue, Oct 03, 2023 at 10:34:48PM +0800, 安阳 wrote:
> Hi，I'm doing "linux from scratch"  recently. I got an error when compiled
> m4.
> [image: 企业微信截图_16963434298603.png]
> gcc version is 13.2.1。Can you help me fix the error。Thanks very much

Posting a screenshot instead of a text paste does not help people who
read your email in plain text mode.  Reproducing the relevant part of
your image here:

  CC   output.o
output.c: In function 'make_room_for':
output.c:488:40: error: potential null pointer dereference 
[-Werror=null-dereference]
  488 |   output_file = output_diversion->u.file;
  |   ~^
cc1: all warnings being treated as errors

Thanks for the report.  If you don't mind ignoring the warning, you
can disable -Werror in your CFLAGS and see if the just-built m4 passes
its testsuite.

If it is a real bug, it's in a corner case not covered by the
testsuite, so any patch to such an issue should also enhance the
testsuite.  If it is instead a false negative, there may be a way to
add an assertion to the code that will silence the compiler; and we
would instead suggest reporting a bug against gcc for the diagnostic.
But until I reproduce it and study the code further, I'm not yet in a
position to say whether the fault is in m4 or in gcc.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.
Virtualization:  qemu.org | libguestfs.org

Re: Question about format.c check for __GNUC_MINOR__ of 6

[Eric Blake]

On Wed, Sep 06, 2023 at 03:08:33PM -0700, Mike Fulton wrote:
> Hello,
> 
> The m4 dev line ( git://git.savannah.gnu.org/m4.git )
> has the following code:
> 
> ```
> #if 4 < __GNUC__ + (6 <= __GNUC_MINOR__)
> # pragma GCC diagnostic push
> # pragma GCC diagnostic ignored "-Wformat-nonliteral"
> #endif
> ```

That expression appears to be designed to reject gcc 3.5 and older,
while accepting 3.6 and newer.

I also wonder if modern gnulib provides a better way to test things
than just open-coding it (as Bruno has done a lot of work testing
features of newer compilers).  This may be one case where ignoring the
diagnostic for older builds is desirable - there comes a point where
you can't please both old and new compilers simultaneously, but the
target that should be warning-free is the newer compiler.

That is, maybe it's time to just rewrite the check to something as
simple as #if 8 <= __GNUC__ (that is, only add the pragmas on a much
newer, albeit arbitrary, point in time)?

Conversely, I see that m4 uses gnulib's lib/c-stack.c, which also has:

/* Pacify GCC 9.3.1, which otherwise would complain about segv_handler.  */
# if 4 < __GNUC__ + (6 <= __GNUC_MINOR__)
#  pragma GCC diagnostic ignored "-Wsuggest-attribute=pure"
# endif

so it's not like m4 is doing anything radically different from gnulib
when it comes to pragmas for ignoring certain diagnostics; but thd
difference may be which diagnostic is being ignored.

> 
> This produces an error on the clang compiler I am using on z/OS, which is
> at 4.2 with the xasprintf code that follows, e.g.
> 
> ```
> str = xasprintf (fstart, width, ARG_INT(argc, argv));
> ```
> 
> If I change the check to:
> 
> ```
> #if 4 < __GNUC__ + (2 <= __GNUC_MINOR__)
> # pragma GCC diagnostic push
> # pragma GCC diagnostic ignored "-Wformat-nonliteral"
> #endif
> ```
> 
> all is good - it compiles clean. The question is whether the check for 6 is
> too high or if the clang compiler on z/OS has a bug (or something else)?

What does clang claim to be?  That is, what do you get for
  print '__GNUC__ __GNUC_MINOR__' | clang -E - | tail -n1

and what is the actual compiler error you got when the build failed on
the original source?

> I haven't been able to determine what level of gcc provides this diagnostic.
> 
> thanks, mike

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.
Virtualization:  qemu.org | libguestfs.org

Re: M4 assembler error on compile

[Eric Blake]

Adding bug-gnulib in cc

On Wed, Aug 16, 2023 at 09:47:33PM -0500, Parzival Wolfram wrote:
> I have run into an issue while compiling M4 1.4.19 for Solaris 7 (per GCC's
> configure, target is "i386-unknown-solaris2.7") using GCC 3.2 and Make 4.4.
> Configuring the source tree goes smoothly, but during the make step, the
> following error is generated (truncated to relevant lines):
> 
> make[3]: Entering directory `/staging/stage2/m4-1.4.19/lib`
>   CC asyncsafe-spin.o
> Assembler: asyncsafe-spin.c
>  aline 310    : Illegal mnemonic
>  aline 310    : syntax error
> make[3]: *** [Makefile:2866: asyncsafe-spin.o] Error 1

This file comes from gnulib, so the problem would need to be fixed
there (if it is not already fixed), and then the next release of m4
would depend on newer gnulib.

> 
> 
> I have found no other references to this "aline 310" error at all online, so
> I'm unsure what info is needed to diagnose, or if my build environment is
> even supported in this case, as the only packaged versions of most software
> for Solaris 7 is ancient.

I'm not sure if gnulib is still actively targetting Solaris 7 systems.
It also looks like this particular file was picked up by indirect
dependencies; m4 is single-threaded, so an asynsafe-spin operation is
not going to be vital to performance; you may be able to just #if out
the inline assembly, if we can figure out why gnulib wanted the file
in the first place, without adversely affecting the behavior of the
compiled m4 binary.

> 
> Any assistance is appreciated.
> 
> 

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.
Virtualization:  qemu.org | libguestfs.org

[sr #110912] Backslash followed by quote treated as escape sequence on Windows.

[Eric Blake]

Follow-up Comment #1, sr #110912 (project m4):

As you pointed out, it is the responsibility of the calling program to pass in
argv[] with expected contents.  Most ports of GNU programs to Windows
environments have their own idioms in place to either alter the shell to have
normal Unix parsing, or to have the CRT normalize the incoming arguments prior
to reaching main() (examples of these environments being Cygwin and MSYS).  In
which case, the problem is in your environment, and not in m4 proper, as the
normalization still happens before main() (whether it happens in the parent
process as with Unix sh, or in the child process).  I don't see how upstream
m4 can do anything about your problem.  What's more, if it is the CRT not
normalizing arguments the way you want, then every other application you
compile with the same CRT will have the same problem.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

Re: Cannot run even a simplest example of define(A, `Harry, MET.')

[Eric Blake]

On Sun, Jun 11, 2023 at 01:42:58PM +0200, 徐心仪 wrote:
> Dear author:
> 
> Sorry to bother you with such an easy problem, but I cannot run even the
> simplest example to quote a string:
> I have tried:
> ```
> define(A, 'Harry, MET.')

Wrong. In m4, the open and close quote sequences must be distinct, in
order to allow nesting of quotes. (Technically, m4 won't complain if
you do try to use changequote to set the open and close quotes to the
same string, but the behavior gets quite weird if you do).  But
surprisingly, it does NOT cause an error out-of-the box; rather, m4
treats an unmatched close quote character as literal text, so executed
like this, you have defined macro "A" to the contents "'Harry, MET.'"
(including the two unmatched ').

> ```
> and
> 
> ```
> define(A, `Harry, MET.')

That is the out-of-the-box default quotation characters, provided you
used actual back-tick and single-quote (ascii \x60 and \x27) and not
some other UTF-8 character accidentally copy-pasted from something
that rendered with "nicer-looking" characters.  If this was your first
line of input to m4, it results in macro "A" having contents "Harry,
MET." (no embedded quoting characters, because the quotes were
stripped while collecting arguments to the define macro).

> ```
> and
> ```
> define(A, [Harry, MET.])

That is only possible if you first used changequote([,]) to change
from `' to [] quoting.  If you are used to programming for autoconf,
that aspect of the environment was already set up for you (mainly
because autoconf focuses on using m4 to produce shell script snippets,
and it is REALLY hard to write shell scripts with unbalanced ` or ',
but fairly easy to see balanced [] in shell scripts, so changing
quoting to [] makes life easier).  Out of the box with `' quoting,
this defines "A" with contents "[Harry, MET.]"; but with a leading
changequote([,]), it would define "A" to contents "Harry, MET.".

> ```
> and
> 
> ```
> define(A, [`Harry, MET.'])

That "works", but does different things depending on the current quote
characters.  Out of the box, it defines "A" to contents "[Harry,
MET.]" (the fact that [ and ] are outside of the `' quoting is
irrelevant; m4 concatenates raw characters with quoted string
contents).  With a leading changequote([,]), it defines "A" to
contents "`Harry, MET.'".

Furthermore, in all of the above, the fact that you did NOT quote
argument A is a potential pitfall; the macro name argument to the
define macro must generally be quoted so as not to inadvertently
trigger macro expansion.  So if you are showing snippets attempted
from a single m4 implementation, where your first messed-up define(A,
'Harry, MET.') was already in force, then your second attempt at
define(A, `Harry, MET.') ends up actually invoking the define macro
with the two arguments "'Harry, MET.'" and "Harry, MET."; not the
macro you intended to have defined.  You REALLY want to write
define(`A', `Harry, MET.') if using default `' quoting.

> ```
> In addition, the manual in http://gnu.ist.utl.pt/software/m4/manual/m4.pdf
> still describes version 1.4.7, however, my m4 version is 1.4.18.
> I tried to build a manual from https://git.savannah.gnu.org/git/m4.git,
> branch 1.4, however, I couldn't do that.
> ```
> autoreconf -i
> sh: 1: build-aux/git-version-gen: not found

You didn't run ./bootstrap first.  bootstrap is only necessary when
checking out from git (if you build from a pre-released tarball, you
don't need to do it).  Building from git is not for the faint of heart
- it requires that you already have a pre-installed working m4 from a
tarball in place (the dependency is not circular, but also not
trivial); which is why we recommend that most users build m4 from
release tarballs rather than from git.

> configure.ac:25: error: AC_INIT should be called with package and version
> arguments
> /usr/share/aclocal-1.16/init.m4:29: AM_INIT_AUTOMAKE is expanded from...
> configure.ac:25: the top level
> autom4te: error: /usr/bin/m4 failed with exit status: 1
> aclocal: error: /usr/bin/autom4te failed with exit status: 1
> autoreconf: error: aclocal failed with exit status: 1
> ```
> 
> Thank you for your precious time!
> 
> Best,
> Xinyi

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3266
Virtualization:  qemu.org | libvirt.org

Re: m4 fails to expand macros after changequote

[Eric Blake]

On Tue, May 16, 2023 at 12:16:17PM +0200, Andreas F. Borchert wrote:
> 
> Here is a minimal example that demonstrates the problem:
> 
>changequote({,})dnl
>define(P1, {changequote([,])`}$[]1{'changequote()})dnl
>changequote()dnl

This line is your problem.  Per POSIX,
https://pubs.opengroup.org/onlinepubs/9699919799/utilities/m4.html

changequote
   The changequote macro shall set the begin-quote and end-quote
   strings. With no arguments, the quote strings shall be set to the
   default values (that is, `'). The behavior is unspecified if there
   is a single argument or either argument is null. With two non-null
   arguments, the first argument shall become the begin-quote string
   and the second argument shall become the end-quote string. Systems
   shall support quote strings of at least five characters.

You have called changequote() which passes a single null argument,
rather than a well-specified behavior of zero arguments or two
non-null arguments.  But even though POSIX says behavior is
unspecified, 'info m4 changequote' does declare what GNU does:

 -- Builtin: changequote ([START = ‘`’], [END = ‘'’])
 This sets START as the new begin-quote delimiter and END as the new
 end-quote delimiter.  If both arguments are missing, the default
 quotes (‘`’ and ‘'’) are used.  If START is void, then quoting is
 disabled.  Otherwise, if END is missing or void, the default
 end-quote delimiter (‘'’) is used.  The quote delimiters can be of
 any length.

Thus, you have managed to disable quoting altogether (m4's choice of
disabling quoting may seem an odd decision, but it was made decades
ago before I started m4 development, and since it is documented, it is
one that is unlikely to be changed due to back-compat concerns).  I
don't know if Solaris m4 documents their behavior, but based on their
behavior and your email, I'm assuming they treat "changequote()" as a
synonym to "changequote".

But I can offer some advice: to be portable to both GNU and Solaris
m4, write:

changequote`'dnl

Since ` is neither ( nor a macro name character, it forces a call of
changequote with zero parameters per POSIX, which in turn restores
quoting to normal, so that the `' is then parsed as an empty string
after quotes are removed.

>define(`foo', `$1 is not P1')dnl

Given your mistake in the line above, this was defining the macro
named "`foo'" (5-character name, non-invokable without indir) rather
than the macro "foo" (3-character name),...

>foo(`bar')

...so this line sees no macro invocations whatsoever, but neither does
it recognize `' as quote characters.

> 
> Running this example with GNU m4:
> 
>theon$ m4 --version
>m4 (GNU M4) 1.4.19
>Copyright (C) 2021 Free Software Foundation, Inc.
>License GPLv3+: GNU GPL version 3 or later 
> <https://gnu.org/licenses/gpl.html>.
>This is free software: you are free to change and redistribute it.
>There is NO WARRANTY, to the extent permitted by law.
> 
>Written by René Seindal.
>theon$ m4 bug.m4
>foo(`bar')
>theon$ 
> 
> In comparison, running this with Solaris 11.4 m4:
> 
>theon$ /usr/bin/m4 bug.m4
>bar is not `$1'
>theon$

Thanks for a nice report, even if the bug turned out to be in your
script rather than in GNU m4 proper.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3266
Virtualization:  qemu.org | libvirt.org

Re: Bug in m4

[Eric Blake]

On Thu, Apr 20, 2023 at 10:59:48AM +1200, Davin Pearson wrote:
> Here is the shell output when I run the command
> 
> cd ~/Peblic/sources && make m4
> 
> Look out for the lines with ERROR in them as they are
> problematic code for the m4 language...
>
...

> make[2]: Entering directory '/home/davin/Peblic/sources/50webs-com/photos'
> echo Toadstool && m4 -P -Dm4_home=.. -Dm4_dirname=photos -Dm4_filename=$X
> -Dm4_is_dos= Alan+Roger+Davin-2014.hts
> >../../../targets/50webs-com/photos/Alan+Roger+Davin-2014.html
> Toadstool
> m4:Alan+Roger+Davin-2014.hts:10: ERROR: end of file in argument list
> make[2]: *** [../../Makefile.mk:149: m4-inner] Error 1

So m4 is reporting that there is a syntax error in your file
Alan+Roger+Davin-2014.hts.  That's not a bug in m4, but in your file.
Without knowing the contents of that file, it is not obvious for me to
tell you why that file is triggering m4 to report a syntax error.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3266
Virtualization:  qemu.org | libvirt.org

Re: Bug in m4

[Eric Blake]

On Sun, Apr 02, 2023 at 01:25:28PM +1200, Davin Pearson wrote:
> The following archive Peblic-20230402-131204.tar.gz when
> extracted fails to build the following targets.  The code takes
> an X.hts (stands for HTml Source) file and converts it to an
> X.html file using GNU m4.
> 
> $cd ~/Peblic/Makefile   && make m4-test
> $cd ~/Peblic/sources/Makefile   && make m4-test
> $cd ~/Peblic/sources/50webs-com && make m4
> 
> The last one fails multiple times when trying to build every file *.hts in
> the folder ~/Peblic/sources/50webs-com

Can you give more details?  What error messages are you getting?  Why
do you think it is a bug in m4, rather than in the Peblic sources?

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3266
Virtualization:  qemu.org | libvirt.org

Re: Frozen fole is read in text mode but created in binary mode.

[Eric Blake]

On Sat, Jan 28, 2023 at 10:31:04PM +0100, Juan Manuel Guerrero wrote:
> I do not know if this issue has already been reported, but for all
> systems that distinguish between binary and text I/O, the file should
> be read in the same mode than it has been created or it may rise reading
> issues.  When a "frozen" file is created in produce_frozen_state() this
> is done using binary mode and that is ok.  But when it later is reloaded,
> the reading is done without specifying the mode and this defaults to
> text mode breaking/aborting the reading process.  The patch below fixes
> the issue but it is only intended as suggestion.  Fix the issue as you
> like.

Thanks for the report.  I'm not sure if calling SET_BINARY() is the
best fix, or if it is better to teach m4_path_search() which files
must be opened in binary mode (vs. in default mode, where the default
mode might be text on platforms where text is distinct from binary).
I'll give it some more thought, but may end up including your patch as
written if I can't think of anything more elegant.

> +++ b/src/freeze.c
> @@ -268,6 +268,7 @@ reload_frozen_state (const char *name)
>file = m4_path_search (name, NULL);
>if (file == NULL)
>  m4_failure (errno, _("cannot open %s"), name);
> +  SET_BINARY (fileno (file));
>    current_file = name;
> 
>allocated[0] = 100;
> 

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3266
Virtualization:  qemu.org | libvirt.org

Re: syscmd broken on FreeBSD and AIX

[Eric Blake]

On Fri, Sep 23, 2022 at 02:38:03AM +0200, Bruno Haible wrote:
> Hi,
> 
> With the current m4 from git (branch-1.4), several tests fail on FreeBSD 13
> and AIX 7.1 and 7.2, indicating that the syscmd built-in is completely
> dysfunctional there:

Thanks for the report.  I'm still thinking about this one...

> The problem can be reproduced interactively:
> 
> $ src/m4
> syscmd(`echo')
> echo: --:  not found.
> m4: syscmd subprocess failed
> 
> What happens, is that this invokes "sh -c -- echo". Which does not work. See:
> 
> $ sh -c -- echo
> echo: --: not found
> $ sh -c -- pwd
> pwd: --: not found
> $ sh -c -- foobar
> foobar: --: not found

That's a bug in sh not being POSIX-compliant.  But no one said sh has to be.

Instead of using -- to force sh to realize the command being passed is
intended to be a script to run (even if it starts with - or +), it is
also possible to prepend a space.  That is, if '-mycommand' is a real
command to be run, then a POSIX sh should treat:

sh -c -- -mycommand
sh -c ' -mycommand'

identically; and on non-POSIX sh, we avoid the misbehavior of -- not working.

I also like your idea of only special-casing command strings that
actually have the problem of a leading - or + (as those are rare),
rather than all command strings.

> 
> On Solaris 10, /bin/sh has the same problem, but the configuration of m4 sets
> SYSCMD_SHELL = "/usr/xpg4/bin/sh", thus working around the problem in an 
> elegant
> way.
> 
> On FreeBSD, bash may or may not be installed as /usr/local/bin/bash (part of
> the ports collection).
> On AIX, bash may or may not be installed as /usr/bin/bash (part of the Bull
> Freeware ports).
> 
> This is a regression, caused by the commit from 2021-11-19 with title
> "syscmd: Allow commands with leading - or +".

Yes, that patch was indeed the source of the regression, and it
stemmed from this discussion in POSIX:

https://www.austingroupbugs.net/view.php?id=1440

> 
> Find attached a patch that limits the new behaviour to the commands that
> actually start with - or +. With this, the set of failed tests shrinks to
> 
> Failed checks were:
>   ../../checks/006.command_li:err ../../checks/196.esyscmd:out 
> ../../checks/196.esyscmd:err ../../checks/197.sysval:out 
> ../../checks/197.sysval:err ../../checks/198.sysval:out 
> ../../checks/198.sysval:err ../../checks/199.mkstemp:err
> 
> The added line
>   prog_args[slot + 1] = NULL;
> is currently technically a nop, but makes the code more future-proof
> (in case more variation is needed in the prog_args array in the future).

I'm thinking of trying the alternative of not injecting "--" after
all, but instead munging the given argument to supply a leading space.
But that we need a new version of your patch.  Do you want to try and
rework it along those lines, or should I make time for that?

> +{
> +  if (cmd[0] == '-' || cmd[0] == '+')
> +/* If cmd starts with '-' or '+', "sh -c $cmd" is not guaranteed to
> +   work.  In this case, use "sh -c -- $cmd".
> +   Note: This requires a POSIX compliant SYSCMD_SHELL.  It does not
> +   work with /bin/sh on FreeBSD 13 and AIX 7, and on these platforms
> +   'bash' is not guaranteed to be installed.  */
> +slot = 3;
> +  else
> +/* For most commands, the traditional "sh -c $cmd" works fine.
> +   Including on FreeBSD 13 and AIX 7.  */
> +slot = 2;
> +}
>prog_args[slot] = cmd;
> +  prog_args[slot + 1] = NULL;
>errno = 0;
>status = execute (ARG (0), SYSCMD_SHELL, prog_args, NULL, false,
>  false, false, false, true, false, _status);
> -- 
> 2.34.1
> 


-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3266
Virtualization:  qemu.org | libvirt.org

[sr #110809] UBSAN failure in output.c:511 (make_room_for)

[Eric Blake]

Update of sr #110809 (project m4):

 Assigned to:None => ericb  

___

Follow-up Comment #2:

Thanks for the useful report, including reproduction instructions that worked
out of the box.  The code is indeed calling memcpy(dest, NULL, 0) which works
on all known libc implementations, but where the sanitizer is indeed correct
that NULL is not a pointer to a valid object (even if we won't be copying from
it).  It is easy enough to work around, so I'll post a patch along those
lines.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

Re: format is locale aware

[Eric Blake]

On Tue, Jun 08, 2021 at 06:16:05PM +0200, Bruno Haible wrote:
> Hi Eric,
> 
> > However, as previous versions of m4 were NOT locale-aware, enabling
> > locale support on what was supposed to be a minor release feels
> > awkward
> 
> Yes; it can break some existing scripts that invoke m4.
> 
> > > If no, the fix would be in main.c: Add a
> > >   setlocale (LC_NUMERIC, "C");
> > > after setlocale (LC_ALL, "").
> > 
> > Or to use gnulib c-strtod and c-vasnprintf modules.
> 
> Well, c-strtod.c spends some time switching the locale. If the program
> does not contain any other uses of the LC_NUMERIC category of the locale
> (and this will also remain true in future versions of m4), it is more
> efficient to switch the LC_NUMERIC category to "C" once and for all.

I'm finally revisiting this thread, and decided to go with your
approach of forcing LC_NUMERIC instead of importing additional gnulib
modules, at least for the 1.4.x branch.

> 
> c-vasnprintf, OTOH, is just as efficient as vasnprintf.
> 
> Bruno
> 

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3266
Virtualization:  qemu.org | libvirt.org

Re: Failing test: "test-posix_spawn-script". Race condition?

[Eric Blake]

On Tue, Dec 20, 2022 at 06:51:31PM -0500, Mitchell Dorrell wrote:
> I'm compiling m4 1.4.19 on a dual-socket server with second-generation AMD
> Epyc processors (128 cores total). I'm compiling using GCC 12.2.0. "make
> -j128 check" fails, but "make check" succeeds. While troubleshooting, I
> noticed that the test reads an empty file instead of one containing the
> expected number of bytes. I'm guessing that another test (running
> concurrently) is interfering with the results of this test.
> 
> Is this a known issue?

Thanks for the report; I'm looping in bug-gnulib as the owners of the
test in question.  It's the first time I've heard of this issue, but I
also know that m4 needs a new release with a newer pull from gnulib,
so the issue may have been addressed in the meantime in gnulib.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3266
Virtualization:  qemu.org | libvirt.org

Re: simple doc point

[Eric Blake]

On Thu, Jun 09, 2022 at 07:26:10PM +0100, Gavin Smith wrote:
> My preferred solution for this at the moment is to add a new command,
> akin to @deftypefnnewline, which would toggle whether a space was
> output after the definition name. It would be included in Texinfo
> source files if required. This would be fairly straightforward to
> implement. In texinfo.tex, the space is output in \defname, and this
> could easily be made conditional:

Adding a new command to suppress the space after \defname sounds
reasonable.  I'd be happy to test how that looks in the m4 manual,
although I'm not a texinfo.tex expert to write such a patch myself.

> 
> diff --git a/doc/texinfo.tex b/doc/texinfo.tex
> index a2bcf60e49..c742b63583 100644
> --- a/doc/texinfo.tex
> +++ b/doc/texinfo.tex
> @@ -7835,7 +7835,7 @@ might help (with 'rm \jobname.?? \jobname.??s')%
>  \fi   % no return type
>  #3% output function name
>}%
> -  {\rm\enskip}% hskip 0.5 em of \rmfont
> +  %\rm\enskip}% hskip 0.5 em of \rmfont
>%
>\boldbrax
>% arguments will be output next, if any.
> 
> 
> Does anyone have any comments?
> 

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3266
Virtualization:  qemu.org | libvirt.org

Re: AIX stackoverflow detection hang [was: Reporting m4 bug]

[Eric Blake]

On Tue, Jun 28, 2022 at 01:10:54PM +, Neha Jain33 wrote:
> Hi,
> 
> I am trying to build m4 package but its hanging during testcase validation

Thanks for the report.  I'm adding in Bruno, as one of the authors of
the libsigsegv library that the code in lib/stackvma.c is derived
from; perhaps he'll have more ideas on what to test next.

> 
> Package details
> m4 1.4.19
> 
> Machine details
> operating system: AIX/PPC
> oslevel: 7.1.0.0
> 
> what is the issue:
> one of the testcase is hanging
> 
> hanged after this
> PASS: test-sigsegv-catch-segv1
> PASS: test-sigsegv-catch-segv2
> PASS: test-sigsegv-catch-stackoverflow1
> 
> ps -ef output:
> root 11010342  7078448   0 05:44:31  pts/0  0:00 /bin/sh 
> ../build-aux/test-driver --test-name test-sigsegv-catch-stackoverflow2 
> --log-file test-sigsegv-catch-stackoverflow2.log --trs-file 
> test-sigsegv-catch-stackoverflow2.trs --color-tests no --enable-hard-errors 
> yes --expect-failure no -- ./test-sigsegv-catch-stackoverflow2
> root 11927964 11010342  61 05:44:31  pts/0 12:57 
> ./test-sigsegv-catch-stackoverflow2
> 
> If I run this testcase manually its working but if we run it with all test 
> cases then its hanging
> # r-tests no --enable-hard-errors yes --expect-failure no -- 
> ./test-sigsegv-catch-stackoverflow2   
><
> + /bin/sh ../build-aux/test-driver --test-name 
> test-sigsegv-catch-stackoverflow2 --log-file 
> test-sigsegv-catch-stackoverflow2.log --trs-file 
> test-sigsegv-catch-stackoverflow2.trs --color-tests no --enable-hard-errors 
> yes --expect-failure no -- ./test-sigsegv-catch-stackoverflow2
> PASS: test-sigsegv-catch-stackoverflow2
> 
> # ./test-sigsegv-catch-stackoverflow2
> + ./test-sigsegv-catch-stackoverflow2
> Starting recursion pass 1.
> Stack overflow 1 caught.
> Starting recursion pass 2.
> Stack overflow 2 caught.
> Segmentation violation correctly detected.
> Segmentation violation correctly detected.
> Test passed.

That's odd that the test is passing in isolation, but not when run as
part of 'make check'.  Is there something that 'make' is changing in
the environment handed to children that could explain why the test
gets confused when invoked through more layers?

> 
> 
> Info on stack
> attached a process to dbx and found below details
> 
> Waiting to attach to process 7733970 ...
> Successfully attached to test-sigsegv-catch-stackoverflow.
> Type 'help' for help.
> reading symbolic information ...
> stopped in is_mapped at line 621 in file ""
> is_mapped(addr = 9), line 621 in "stackvma.c"
> is_unmapped(addr1 = 4, addr2 = 15), line 768 in "stackvma.c"
> mincore_is_near_this(addr = 10, vma = 0x000111001fb8), line 793 in 
> "stackvma.c"
> unnamed block in sigsegv.sigsegv_handler(sig = 11, sip = 0x000111002310, 
> ucp = 0x000111002060), line 973 in "sigsegv.c"
> unnamed block in sigsegv.sigsegv_handler(sig = 11, sip = 0x000111002310, 
> ucp = 0x000111002060), line 973 in "sigsegv.c"
> sigsegv.sigsegv_handler(sig = 11, sip = 0x000111002310, ucp = 
> 0x000111002060), line 973 in "sigsegv.c"
> main(), line 183 in "test-sigsegv-catch-stackoverflow2.c"
> 
> code snippet
> location:/home/buildusr/rpmbuild/BUILD/m4-1.4.19/64bit/lib/stackvma.c
> seems like its stuck here in for loop
> 
>   754   for (;;)
> 755 {
> 756   uintptr_t addr_stepsize;
> 757   uintptr_t i;
> 758   uintptr_t addr;
> 759
> 760   stepsize = stepsize / 2;
> 761   if (stepsize == 0)
> 762 break;
> 763   addr_stepsize = stepsize * pagesize;
> 764   for (i = stepsize, addr = addr1 + addr_stepsize;
> 765i < count;
> 766i += 2 * stepsize, addr += 2 * addr_stepsize)
> 767 /* Here addr = addr1 + i * pagesize.  */
> 768 if (is_mapped (addr))
> 769   return 0;
> 770 }
> 
> configure details
> ./configure --prefix=%{_prefix} \
> --mandir=%{_mandir} \
>     --infodir=%{_infodir} \
> --enable-largefile

At this point, I don't have access to an AIX machine.  Since you have
attached a debugger, what values do stepsize, addr1, and pagesize
have?  stepsize looks like it is supposed to decrease each iteration
of the loop, and that the loop will break if it decreases to 0.  Is
that actually happening?

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3266
Virtualization:  qemu.org | libvirt.org

Re: simple doc point

[Eric Blake]

8335,9 @@ Improved copy
 two-argument @code{pushdef} call sequence needed, so that we are no
 longer passing a builtin token through a text macro.

-@deffn Composite stack_foreach_sep (@var{macro}, @var{pre}, @var{post}, @
+@deffn Composite stack_foreach_sep(@var{macro}, @var{pre}, @var{post}, @
   @var{sep})
-@deffnx Composite stack_foreach_sep_lifo (@var{macro}, @var{pre}, @
+@deffnx Composite stack_foreach_sep_lifo(@var{macro}, @var{pre}, @
   @var{post}, @var{sep})
 For each of the @code{pushdef} definitions associated with @var{macro},
 expand the sequence @samp{@var{pre}`'definition`'@var{post}}.



-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3266
Virtualization:  qemu.org | libvirt.org

Re: I can't compile m4

[Eric Blake]

On Sun, May 15, 2022 at 03:19:27PM +0300, Ilya wrote:
> Hello.
> 
> My system:
> Windows 7 x64
> I tried:
> mingw32-make.exe(v3.82.90), gcc.exe(v9.2.0)
> mingw32-make.exe(v4.3), gcc.exe(v11.3.0)
> sh.exe(v4.4.23.2)
> sh.exe(v5.1.8.1)
> 
> Please help me to compile m4 v1.4.18 (or 1.4.19).
> I used MinGW and MinGW-W64 and MSYS2 distrs.
> I think the problem with generating of math.h
> 

>   GEN  limits.h
>   GEN  locale.h
> /usr/bin/sh: -c: line 212: unexpected EOF while looking for matching `''
> /usr/bin/sh: -c: line 213: syntax error: unexpected end of file
> mingw32-make[2]: *** [Makefile:2400: math.h] Error 1
> mingw32-make[2]: Leaving directory 'R:/W7X64/BUILD/m4/SRC/v1.4.18/lib'
> mingw32-make[1]: *** [Makefile:1572: all-recursive] Error 1
> mingw32-make[1]: Leaving directory 'R:/W7X64/BUILD/m4/SRC/v1.4.18'
> mingw32-make: *** [Makefile:1528: all] Error 2

Could there be some carriage return corruption in your files (either
the generated math.h itself, or in the generated Makefile produced by
configure), that results in the syntax errors?  At the moment, I don't
have handy access to a mingw system to attempt to reproduce your
issue.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3266
Virtualization:  qemu.org | libvirt.org

Re: m4 1.4.19 with musl libc 1.2.3 fails test-posix_spawn_file_actions_addclose

[Eric Blake]

Forwarding to gnulib, which owns this test.

On Mon, Apr 11, 2022 at 12:15:47PM +0200, Natanael Copa wrote:
> ncopa-desktop:~/aports/main/m4/src/m4-1.4.19 (master)$ cat 
> tests/test-suite.log 
> =
>GNU M4 1.4.19: tests/test-suite.log
> =
> 
> # TOTAL: 267
> # PASS:  235
> # SKIP:  31
> # XFAIL: 0
> # FAIL:  1
> # XPASS: 0
> # ERROR: 0
> 
> .. contents:: :depth: 2
> 
> ...
> 
> FAIL: test-posix_spawn_file_actions_addclose
> 
> 
> test-posix_spawn_file_actions_addclose.c:62: assertion 
> 'posix_spawn_file_actions_addclose (, bad_fd) == EBADF' failed
> Aborted
> FAIL test-posix_spawn_file_actions_addclose (exit status: 134)
> 
> Seems like the test assumes behavior that is not mandatory in POSIX, so 
> technically, the test is wrong.
> 
> -nc
> 

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3266
Virtualization:  qemu.org | libvirt.org

Re: Make check - test-vasprintf-posix failure - darwin12 - macos

[Eric Blake]

On Mon, Mar 28, 2022 at 12:51:10AM +, Gaëtan HERFRAY wrote:
> Hello,
> 
> I'm trying to compile M4-1.4.19 on macOS, and I ran :
> 
> ./configure
> make
> make check
> 
> Actually, make check is failing on test-vasprintf-posix.

Thanks for the report.  This test is maintained by gnulib, so other
projects may see the same failure in that test.  Or it may have been
fixed in the meantime (I still need to release an updated version of
m4).

> After investigating, I found that they are 3 tests that are failing, about
> pseudo denormal (you can find the four tests by looking for "{ LDBL80_WORDS
> (0x, 0x8333, 0x) }".
> 
> Only the first one pass, the three next are failing.
> 
> First question: are those tests important?

They are important to gnulib, as it helps find places where we still
need to work around platform bugs.  But they are less important to m4,
which does not output floating point numbers, and therefore does not
need to worry about printf() bugs in dealing with pseudo-denormal bit
values.

> 
> For help with investigation, I found that by replacing 0x8333
> to 0x6333 will make the tests pass, but I don't know what the impacts
> are as I'm absolutely not a C developer.
> 
> Note:
> 
> After reading here:
> https://lists.gnu.org/archive/html/bug-m4/2013-06/msg0.html I also
> tried running ./configure gl_cv_func_printf_directive_a=no, but no chance
> of making it working.
> 
> The only solution I found is by commenting the three last tests
> about Pseudo-Denormal directly in tests/test-vasprintf-posix.c
> 
> Thanks a lot

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3266
Virtualization:  qemu.org | libvirt.org

Re: m4-1.4.17 make error

[Eric Blake]

On Tue, Mar 08, 2022 at 05:55:11PM +0300, Seniha Çelik wrote:
> Hello,
> I am facing with a problem, so I need some help.
> I am using Ubuntu 20.04 and trying to install m4-1.4.17. I need the older
> version to run a program, that's why I am using this version.

Why do you need the older version?  This issue has been fixed in newer
releases.

> gcc  -I. -g -O2 -MT freadahead.o -MD -MP -MF $depbase.Tpo -c -o
> freadahead.o freadahead.c &&\
> mv -f $depbase.Tpo $depbase.Po
> freadahead.c: In function 'freadahead':
> freadahead.c:91:3: error: #error "Please port gnulib freadahead.c to your
> platform! Look at the definition of fflush, fread, ungetc on your system,
> then report this to bug-gnulib."

This is a known issue with mixing old m4 builds with newer libc.  The
solution is to either build with older libc, or to upgrade to a newer
build of m4, or to manually backport the fix from newer m4 on top of
your older m4 build (if you can even come up with a convincing reason
why newer m4 will not work for your needs).

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3266
Virtualization:  qemu.org | libvirt.org

Re: m4-1.4.17 abort trap

[Eric Blake]

On Sat, Jan 29, 2022 at 04:58:24PM +0100, Luciano wrote:
> Hallo gnu,
> 
> 0) thanks a lot for your work on free software!
> 1) I have a fresh install of OpenBSD 7.0 [i386]
>and i tried to install m4-1.4.17.

That version is several years old.  Can you try again with 1.4.19, and
see if the issue has been fixed in the meantime?

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3266
Virtualization:  qemu.org | libvirt.org

Re: Assertion error when building in Debug mode with MSVC

[Eric Blake]

[adding bug-gnulib]

On Mon, Jan 24, 2022 at 05:00:01PM +0100, Julien Marrec wrote:
> Hello,
> 
> I realize this is probably not a combination of platform, compiler and
> build type that you anticipated. m4 is used in a conan - the C++ package
> manager - recipe, and it serves as the basis for many other recipes (such
> as bison).
> 
> We encountered an issue when building it with Visual Studio (2019 for eg)
> in *Debug* mode (runtime MDd). At runtime, even `m4.exe --version` will
> throw the following assertion in ucrt.dll
> 
> ```
> minkernel\crts\ucrt\src\appcrt\lowio\close.cpp(49) : Assertion failed:
> (_osfile(fh) & FOPEN)
> ```
> 
> It seems that there is a double close happening, apparently from something
> gnulib overrides, as this small example produces exactly the same error:
> 
> ```
> 
> #include 
> #include int main() {
> int no =  _fileno (stdin);
> _close(no);
> fclose(stdin);
> }
> 
> ```

fclose() asserting because the underlying fd has been previously
closed seems odd; is it something that gnulib should work around by
overriding fclose() to be guaranteed that it has an open fd?

This may be fallout from the gnulib module closeout (and the function
close_stdout), trying hard to ensure that any write failures to stdout
are properly detected.  That may be the spot where we would add a
workaround to your platform's assertion failure in fclose().

> 
> An issue can be found there:
> https://github.com/conan-io/conan-center-index/issues/8920
> An older discussion with more information is here:
> https://github.com/conan-io/conan-center-index/pull/7369#issuecomment-927159346
> 
> I have implemented a poor-man's workaround for the time being which
> consists in calling _CrtSetReportMode early in the main function of m4.c so
> that the popup isn't triggered and instead it prints to the console, but I
> would ideally like to see if there isn't a small patch we could do to avoid
> the double close to begin with.
> 
> Could you help please?
> 
> Thank you for your time and contributions!
> Best,
> Julien
> --
> Julien Marrec, EBCP, BPI MFBA
> Owner at EffiBEM <http://www.effibem.com>
> T: +33 6 95 14 42 13
> 
> LinkedIn (en <https://www.linkedin.com/in/julienmarrec>) *| *(fr
> <https://fr.linkedin.com/in/julienmarrec/fr>) :
> <http://www.linkedin.com/in/julienmarrec>

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3266
Virtualization:  qemu.org | libvirt.org

Re: pkg/56336 (m4 fails to build on Solaris 10)

[Eric Blake]

On Wed, Oct 27, 2021 at 09:35:37AM +0900, 箱山洋 wrote:
> Dear m4 developers,
> 
> I found a bug of m4-1.4.19 on Solaris 10 (SPARC), so I sent a bug report to 
> pkgsrc (http://gnats.netbsd.org/56336).
> 
> The message says:
> ./m4: internal error detected; please report this bug to : 
> Illegal instruction
> 
> So, I also forward the bug report to bug-m4.

Thanks for the report.

>   CC   stackvma.o
> In file included from stackvma.c:1476:0:
> /usr/include/sys/procfs.h:44:2: error: #error "Cannot use procfs in the large 
> file compilation environment"
>  #error "Cannot use procfs in the large file compilation environment"
>   ^
> *** Error code 1
> ...
> 
> This error is similar to the report at 
> https://lists.gnu.org/r/bug-m4/2021-05/msg00020.html
> https://lists.gnu.org/r/bug-m4/2021-05/txtSlhgMVQhua.txt

Indeed, and yet another reason why I need to make time to release m4
1.4.20 with that fix already included.

> m4 was able to built by this patch, but the execution of m4 showed an error:
> 
> # ./m4
> *** stack smashing detected ***:  terminated
> ./m4: internal error detected; please report this bug to : 
> Illegal instruction
> 
> # /usr/pkgsrc/devel/m4/work/.destdir/usr/pkg/bin/gm4 
> *** stack smashing detected ***:  terminated
> /usr/pkgsrc/devel/m4/work/.destdir/usr/pkg/bin/gm4: internal error detected; 
> please report this bug to : Illegal instruction

Can you run this under a debugger to get the stack trace of where the
error occurs?

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3266
Virtualization:  qemu.org | libvirt.org

Re: Bug in dumpdef's documentation

[Eric Blake]

On Tue, Oct 26, 2021 at 07:45:06PM +0200, Patrice Dumas wrote:
> > @c @tabchar{}
> > @c --
> > @c The testsuite expects literal tab output in some examples, but
> > @c literal tabs in texinfo lead to formatting issues.
> > @macro tabchar
> > @   @c
> > @end macro
> > 
> > So maybe the problem is that the macro expansion is leaving a bare @c
> > which then eats the rest of the line when using the macro within
> > @example.
> 
> It is indeed what happens, the expansion of the texinfo conserves the
> @c. (macro expansion can be tested with the -M option).  So `Hello world.'
> and  disappear:
> 
...
> One possibility is to add an end of line in the macro definition, which
> should work for texi2any:
> 
> @c @tabchar{}
> @c --
> @c The testsuite expects literal tab output in some examples, but
> @c literal tabs in texinfo lead to formatting issues.
> @macro tabchar
> @ @c
> 
> @end macro
> 
> However, this needs to be tested with texi2pdf, as texi2pdf may need
> something else.

Yay, that did it!  I tested info, html, and pdf output, and all of
them rendered the way I wanted once I added the newline (my worry was
an unexpected mid-line break appearing in the rendered example, but
thankfully that did not happen); and the testsuite still passed (it
extracts @examples from the manual, and uses sed to convert @tabchar{}
into a literal tab to match what m4 actually produces).

I'll commit the fix into m4.git shortly, although the online manual
won't be updated until the 1.4.20 release.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3266
Virtualization:  qemu.org | libvirt.org

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

[Eric Blake]

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

Re: Bug in dumpdef's documentation

[Eric Blake]

On Tue, Oct 26, 2021 at 02:30:26AM +0200, 4dr14n31t0r Th3 G4m3r wrote:
> The output documented is not what you get from executing the m4 commands as
> documented. See https://www.gnu.org/software/m4/manual/m4.html#Dumpdef

Thanks for the report.  More details would have been nice (what you
think was wrong, and what you were expecting), but I can reproduce
that where the manual says:

dumpdef(`foo')
error→foo: ⇒

in practice (given the earlier definition of foo in the example), it should be:

dumpdef(`foo')
error→foo:  `Hello world.'
⇒

Looking at the source, in doc/m4.texi, there is:

@example
$ @kbd{m4 -d}
define(`foo', `Hello world.')
@result{}
dumpdef(`foo')
@error{}foo:@tabchar{}`Hello world.'
@result{}
dumpdef(`define')
@error{}define:@tabchar{}
@result{}
@end example

My initial guess is that there is a bug in the texi -> html conversion
where @tabchar{} gets eaten incorrectly, resulting in the html output
omitting the rest of the intended line.  But checking just now, I see
the same problem in 'info m4' on the corresponding page, so it is not
a bug in the conversion, but in the m4.texi source itself.  Earlier in
the m4.texi, there is:

@c @tabchar{}
@c --
@c The testsuite expects literal tab output in some examples, but
@c literal tabs in texinfo lead to formatting issues.
@macro tabchar
@   @c
@end macro

So maybe the problem is that the macro expansion is leaving a bare @c
which then eats the rest of the line when using the macro within
@example.

I'm cc'ing the texinfo list to see if someone can figure out the
correct magic to use faster than I can.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3266
Virtualization:  qemu.org | libvirt.org

Re: also in C11 mode I get a bug

[Eric Blake]

On Mon, Sep 13, 2021 at 12:44:23AM -0400, Dennis Clarke wrote:
> 
> With std9899:2011 we compile fine but testsuite fails :
> 
> .
> .
> .
> Checking ./stackovf.test
> Stack soft limit set to 300K
> Pass
> 
> Skipped checks were:
>   ./125.changeword ./126.changeword ./127.changeword ./128.changeword
> ./129.changeword ./130.changeword
> Failed checks were:
>   ./198.sysval:err
> gmake[3]: *** [Makefile:2065: check-local] Error 1
> gmake[3]: Leaving directory
> '/opt/bw/build/m4-1.4.19_sunos5.10_sparcv9.002/checks'
> gmake[2]: *** [Makefile:1941: check-am] Error 2
> gmake[2]: Leaving directory
> '/opt/bw/build/m4-1.4.19_sunos5.10_sparcv9.002/checks'
> gmake[1]: *** [Makefile:2018: check-recursive] Error 1
> gmake[1]: Leaving directory '/opt/bw/build/m4-1.4.19_sunos5.10_sparcv9.002'
> gmake: *** [Makefile:2317: check] Error 2
> 
> 
> Not sure what to make of that.

You truncated the log, not showing the actual failure at the time test
198 was run. However, I suspect that you have hit this known issue:

https://lists.gnu.org/archive/html/bug-m4/2021-06/msg9.html

and that your just-built m4 is working just fine.  I still need to
make time to release m4 1.4.20 that fixes that and also the reported
issue about unintended locale sensitivity in the format macro.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3266
Virtualization:  qemu.org | libvirt.org

Re: m4-1.4.19 not C99 clean ?

[Eric Blake]

Adding bug-gnulib, since...

On Mon, Sep 13, 2021 at 12:36:12AM -0400, Dennis Clarke wrote:
> 
> Not sure if this is a bug if m4 is not supposed to be C89 or C99 clean
> however I see :
> 
> .
> .
> .
> /opt/bw/bin/gmake  all-am
> gmake[3]: Entering directory
> '/opt/bw/build/m4-1.4.19_sunos5.10_sparcv9.001/lib'
> source='asyncsafe-spin.c' object='asyncsafe-spin.o' libtool=no \
> DEPDIR=.deps depmode=dashXmstdout /opt/bw/bin/bash ../build-aux/depcomp \
> /opt/developerstudio12.6/bin/c99  -I.   -I/opt/bw/include
> -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO
> -D_FILE_OFFSET_BITS=64 -D_XOPEN_SOURCE=600 -D_REENTRANT  -Xc
> -errtags=yes -errwarn=%none -m64 -xarch=sparc -xO0 -g -xs -errfmt=error
> -erroff=%none -errshort=full -xstrconst -xildoff -xmemalign=8s
> -xnolibmil -xcode=pic32 -xregs=no%appl -xlibmieee -mc -ftrap=%none
> -xbuiltin=%none -xunroll=1 -Qy -xdebugformat=dwarf -c -o
> asyncsafe-spin.o asyncsafe-spin.c
> "asyncsafe-spin.c", line 213: error: undefined symbol: asm
> "asyncsafe-spin.c", line 213: error: syntax error before or at: volatile
> "asyncsafe-spin.c", line 238: error: undefined symbol: asm
> "asyncsafe-spin.c", line 238: error: syntax error before or at: volatile
> c99: acomp failed for asyncsafe-spin.c

...asyncsafe-spin.c comes from gnulib.

> gmake[3]: *** [Makefile:2869: asyncsafe-spin.o] Error 2
> gmake[3]: Leaving directory
> '/opt/bw/build/m4-1.4.19_sunos5.10_sparcv9.001/lib'
> gmake[2]: *** [Makefile:2481: all] Error 2
> gmake[2]: Leaving directory
> '/opt/bw/build/m4-1.4.19_sunos5.10_sparcv9.001/lib'
> gmake[1]: *** [Makefile:2018: all-recursive] Error 1
> gmake[1]: Leaving directory '/opt/bw/build/m4-1.4.19_sunos5.10_sparcv9.001'
> gmake: *** [Makefile:1974: all] Error 2
> 
> Where we see the asm usage that sort of says "not C99 here".
> 
> However std9899:2011 seems to be just fine.
> 
> So are we C11 here only ?

I'm not sure how much of gnulib still tries to cater to C89,
vs. assuming C99.  But if there is an obvious fix for your compiler,
we're likely to use it.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3266
Virtualization:  qemu.org | libvirt.org

Re: Build m4 on RHEL 8

[Eric Blake]

On Tue, Jul 06, 2021 at 04:38:41PM +, Duncan,Michael wrote:
> Hello,
> 
> I am attempting to build a bison 3.7 module on a HPC cluster running RHEL 8.1
> 
> bison 3.7 requires gcc and m4 modules to build, so I am attempting to build 
> the m4 module version 1.4.18

Try using m4 1.4.19 instead.
https://lists.gnu.org/archive/html/m4-announce/2021-05/msg2.html

>   CC   freadahead.o
> freadahead.c: In function 'freadahead':
> freadahead.c:92:3: error: #error "Please port gnulib freadahead.c to your 
> platform! Look at the definition of fflush, fread, ungetc on your system, 
> then report this to bug-gnulib."
>92 |  #error "Please port gnulib freadahead.c to your platform! Look at 
> the definition of fflush, fread, ungetc on your system, then report this to 
> bug-gnulib."
>   |   ^

Known issue with older gnulib, that has since been resolved by the
newer m4 release using newer gnulib.

> 
> The information contained in this e-mail message may be privileged, 
> confidential, and/or protected

Note that your employer's disclaimer is not enforceable on a
publicly-archived mailing list; many users choose to send from
personal email in order to avoid slamming the list with such legalese.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3266
Virtualization:  qemu.org | libvirt.org

Re: Discrepancy in regards to program_name output

[Eric Blake]

On Wed, Jun 09, 2021 at 06:46:45PM +0200, Sören Tempel wrote:
> Hello,
> 
> I was debugging m4 test failures in an Alpine Linux Edge RISC-V RV64
> chroot emulated using qemu-user. The test failures looked as follows:
> 
>   checks$ ./check-them -I ../examples/ 021.macro_argu
>   -/usr/bin/m4:stdin:1: Warning: too few arguments to builtin `index'
>   -/usr/bin/m4:stdin:3: Warning: excess arguments to builtin `index' 
> ignored
>   +m4:stdin:1: Warning: too few arguments to builtin `index'
>   +m4:stdin:3: Warning: excess arguments to builtin `index' ignored
> 
> As one can see, the problem here is that the program name in the output
> differs. Once the full path is used and once it only uses the base name.

Thanks for the report.  We have also encountered the issue when
building m4 for Windows:
https://lists.gnu.org/archive/html/bug-m4/2021-05/msg00019.html

>
> As it turns, out this is due a discrepancy in regards to the handling of
> argv[0] in the m4 soure code. The check-them script attempts to
> determine how m4 prints argv[0] using the following code:
> 
>   # Find out how the executable prints argv[0]
>   m4name=`"$m4" --help | ${SED} -e 's/Usage: \(.*\) \[OPTION.*/\1/' \
>   -e 's///g' -e 1q`
> 
> That is, it extracts argv[0] from the usage string in the --help output.
> This argv[0] value is then added to the expected output. This usage
> string is generated using the following code from src/m4.c:
> 
>   xprintf ("Usage: %s [OPTION]... [FILE]...\n", program_name);
> 
> In this case, program_name is defined by the m4 header file progname.h
> which is included in src/m4.c and set using set_program_name from
> lib/progname.c based on argv[0] as passed to main().
> 
> Unfortunately, the error messages generated by m4 (e.g. `Warning: too
> few arguments to builtin `index'` from above) use a different technique
> to determine the program name. The output of error messages can be
> traced to the file lib/error.c (which seems to have been copied from the
> glibc source code). The lib/error.c file adds the program name to the

Rather, imported from gnulib, but gnulib tends to stay close to glibc.

> error output. However, since it has been copied from glibc it does not
> use the m4-specific progname.h. Instead, it has a it's own ifdef jungle
> to determine a technique for extracting the program name. On my system,
> it ultimately uses program_invocation_short_name via lib/getprogname.c.
> Since program_invocation_short_name is set by the libc, it can differ
> from the program_name value as used in the usage string. In fact,
> program_invocation_short_name is the basename of argv[0], thereby
> causing it to differ from the value extracted from the --help output.
> 
> tl;dr If argv[0] is a full path (e.g. because of qemu-user usage),
> many tests will fail because --help uses argv[0] while error messages
> use basename(argv[0]).
> 
> Not sure how to resolve this, if getprogname is expected to return
> basename(argv[0]) the following comment in lib/progname.c is incorrect,
> since getprogname, not lib/program.c is used for error messages:
> 
>   /** But don't strip off a leading / in general, because when 
> the user runs
> /some/hidden/place/bin/cp foo foo
>   he should get the error message
> /some/hidden/place/bin/cp: `foo' and `foo' are the same file
>   not
> cp: `foo' and `foo' are the same file
>   */

Bruno's suggestion for fixing things on Windows should also fix your
use case; I'm planning on improving the program name substitution in
checks/check-them to filter out any absolute name in argv[0]; while it
is still desirable in the common case (per the comment you quoted) for
output to include a full path name when available, it is unpredictable
enough (whether because of native Windows always passing an absolute
path name in even when invoked by a relative name, or due to argv[0]
rewriting when executing via qemu in your situation, or ...) that
having the test just focus on basenames is going to be more reliable.

We've got enough other issues reported with m4 1.4.19 that I will be
releasing 1.4.20 sometime this summer, and this issue will be one of
the things fixed by that release.

> 
> I am not subscribed to the list, please CC me.

Yes, it's list policy to reply-all.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3266
Virtualization:  qemu.org | libvirt.org

Re: format is locale aware

[Eric Blake]

On Tue, Jun 08, 2021 at 04:15:36AM +0200, Bruno Haible wrote:
> Hi,
> 
> After building m4-1.4.19 on DragonFly BSD 6.0, with LC_ALL=fr_FR.UTF-8,
> "make check" shows a test failure:
> 

> And indeed, the src/m4 program behaves in a locale dependent manner:
> 
> $ src/m4
> format(`%.0f', `9.9')
> src/m4:stdin:1: non-numeric argument 9.9
> 9
> format(`%.0f', `9,9')
> 10
> format(`%.1f', `4')
> 4,0

Thanks for the report. This is an unintended regression introduced by
the fact that 1.4.19 was the first version to change the program
locale away from the default of "C" in order to allow gettext to work.

> 
> I see the same behaviour also on a glibc system.
> 
> 1) Is the number parsing and printing of numbers in 'format' supposed to
> be locale dependent? If yes, it would be good to document it in
> https://www.gnu.org/software/m4/manual/html_node/Format.html .

Format is not a POSIX-mandated macro, so we can make whatever decision
we want about its behavior.

However, as previous versions of m4 were NOT locale-aware, enabling
locale support on what was supposed to be a minor release feels
awkward; it might be better to make m4 1.4.x remain
locale-independent, and reconsider enabling locale support (possibly
via an opt-in mechanism) for future 1.6 or 2.0 releases.

I'm also aware of someone that has been considering posting a patch
that would teach the eval() builtin to operate on floating point.  The
eval macro IS specified by POSIX, but leaves behavior unspecified for
non-integral input, so there is some wiggle room to allowing
floating-point math by default.  Still, having it be opt-in would
coincide with whether floating point parsing and results should be
locale-dependent, at the same time as format.

> If no, the fix would be in main.c: Add a
>   setlocale (LC_NUMERIC, "C");
> after setlocale (LC_ALL, "").

Or to use gnulib c-strtod and c-vasnprintf modules.

> 
> 2) Why do I see the test 180 fail on DragonFly BSD but not on a glibc
> system? In both cases, I have LC_ALL set to fr_FR.UTF-8, and this locale
> exists (verified with 'locale -a').

May be due to differences in strtod() parsing on those platforms, or
something we may have overlooked in gnulib.  Definitely worth some
further investigation, especially if it persists with the use of the
c-strtod module.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3266
Virtualization:  qemu.org | libvirt.org

[sr #110502] 1.4.19: test suite is failing

[Eric Blake]

Follow-up Comment #3, sr #110502 (project m4):

[comment #2 comment #2:]
> > These are gnulib unit test failures; I'll forward your report there.  They
do not affect the operation of m4 itself.
> 
> It affects building and testing procedures.
> 
> OK. So why m4 executest gnulib test units?

Because m4 uses gnulib.  Sometimes a gnulib unit test failure DOES indicate a
problem that will be observable through m4 as well; and even if a gnulib unit
test failure does not indicate a problem for m4, it may indicate a problem for
other gnulib clients.

As it is, m4 only runs the gnulib unit tests for the actual gnulib modules in
use by m4, and not all possible gnulib unit tests.


___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[PATCH] tests: Fix 198.sysval

[Eric Blake]

In my attempt to avoid test failures on Haiku, I caused test failures
on platforms where sh is noisy when reporting a killed sub-process.

* doc/m4.texi (Sysval): Avoid stderr noise during test.
Fixes: 17011ea76a (tests: Skip signal detection on Haiku)
Fixes: https://lists.gnu.org/archive/html/bug-m4/2021-05/msg00029.html
---
 doc/m4.texi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/doc/m4.texi b/doc/m4.texi
index 247f2be5..3b833b2a 100644
--- a/doc/m4.texi
+++ b/doc/m4.texi
@@ -6756,7 +6756,7 @@ Sysval
 ')m4exit(`77')')dnl
 changequote(`[', `]')
 @result{}
-syscmd([/bin/sh -c 'kill -9 $$'; st=$?;
+syscmd([@{ /bin/sh -c 'kill -9 $$'; @} 2>/dev/null; st=$?;
 test $st = 137 || test $st = 265])
 @result{}
 ifelse(sysval, [0], , [errprint([ skipping: shell does not send signal 9
-- 
2.31.1

Re: [sr #110501] Plese convert all po/*.po fiels to UTF-8

[Eric Blake]

Forwarding this to the translation project.

On Tue, Jun 01, 2021 at 05:40:38AM -0400, Tomasz Kłoczko wrote:
> URL:
>   <https://savannah.gnu.org/support/?110501>
> 
>  Summary: Plese convert all po/*.po fiels to UTF-8
>  Project: GNU M4

> Currently most of the systems are using UTF-8 based locale settings.
> Whhen .po file is in non UTF-8 encoding it causes that generated .mo file is
> in teh esame encoding. This is causing that when actually .mo file is used
> (g)glibc must on the fly convert it to UTF-8.
> 
> [tkloczko@barrel po]$ grep charset= *po
> bg.po:"Content-Type: text/plain; charset=UTF-8\n"
> cs.po:"Content-Type: text/plain; charset=ISO-8859-2\n"
> da.po:"Content-Type: text/plain; charset=ISO-8859-1\n"
> de.po:"Content-Type: text/plain; charset=ISO-8859-1\n"
> el.po:"Content-Type: text/plain; charset=iso-8859-7\n"
> eo.po:"Content-Type: text/plain; charset=utf-8\n"
> es.po:"Content-Type: text/plain; charset=UTF-8\n"
> fi.po:"Content-Type: text/plain; charset=UTF-8\n"
> fr.po:"Content-Type: text/plain; charset=UTF-8\n"
> ga.po:"Content-Type: text/plain; charset=ISO-8859-1\n"
> gl.po:"Content-Type: text/plain; charset=UTF-8\n"
> hr.po:"Content-Type: text/plain; charset=UTF-8\n"
> id.po:"Content-Type: text/plain; charset=ISO-8859-1\n"
> ja.po:"Content-Type: text/plain; charset=UTF-8\n"
> ko.po:"Content-Type: text/plain; charset=UTF-8\n"
> nl.po:"Content-Type: text/plain; charset=UTF-8\n"
> pl.po:"Content-Type: text/plain; charset=UTF-8\n"
> pt_BR.po:"Content-Type: text/plain; charset=UTF-8\n"
> ro.po:"Content-Type: text/plain; charset=ISO-8859-2\n"
> ru.po:"Content-Type: text/plain; charset=KOI8-R\n"
> sr.po:"Content-Type: text/plain; charset=UTF-8\n"
> sv.po:"Content-Type: text/plain; charset=ISO-8859-1\n"
> uk.po:"Content-Type: text/plain; charset=UTF-8\n"
> vi.po:"Content-Type: text/plain; charset=utf-8\n"
> zh_CN.po:"Content-Type: text/plain; charset=UTF-8\n"
> zh_TW.po:"Content-Type: text/plain; charset=UTF-8\n"

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3266
Virtualization:  qemu.org | libvirt.org

[sr #110501] Plese convert all po/*.po fiels to UTF-8

[Eric Blake]

Update of sr #110501 (project m4):

  Status:None => Confirmed  
 Open/Closed:Open => Closed 

___

Follow-up Comment #1:

Thanks for the report.  I am forwarding this request to the translation
project, since they are the source of these files.  Nothing that m4.git can do
about it, although the release project automatically picks up any changes made
by the translation project.  As such, I'm closing this, not because the
conversion is complete, but because the translation project does not use this
bug tracker.

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[sr #110502] 1.4.19: test suite is failing

[Eric Blake]

Follow-up Comment #1, sr #110502 (project m4):

comment #0 original submission:]
> Liooks like some files are missing in dist tar ball.
> 
> Please next time generate that tar ball using "distchec" target instead just
"dist".

The tarball WAS generated with 'make distcheck', and passed on my machine. 
There are no missing files in the tarball itself; however, skipped tests
within the gnulib unit tests are normal based on what your system has
available.


> FAIL: test-posix_spawn-dup2-stdout
> ==
> 
> subprocess failed: No such file or directory
> FAIL test-posix_spawn-dup2-stdout (exit status: 1)
> 
> FAIL: test-posix_spawn-dup2-stdin
> =
> 
> subprocess failed: No such file or directory
> FAIL test-posix_spawn-dup2-stdin (exit status: 1)

These are gnulib unit test failures; I'll forward your report there.  They do
not affect the operation of m4 itself.


___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

Re: test failure on Haiku

[Eric Blake]

On Sat, May 29, 2021 at 05:06:00AM -0500, Hanspeter Niederstrasser wrote:
> Hello,
> 
> I'm not on Haiku, but on macOS 10.14.6 and am having a similar test failure
> with m4-1.4.19 and 198.sysval:
> 
> Checking ./197.sysval
> Checking ./198.sysval
> @ ../doc/m4.texi:6751: Origin of test
> ./198.sysval: stderr mismatch
> --- m4-tmp.38611/m4-xerr  2021-05-29 04:47:35.0 -0500
> +++ m4-tmp.38611/m4-err   2021-05-29 04:47:35.0 -0500
> @@ -0,0 +1 @@
> +sh: line 1: 40596 Killed: 9   /bin/sh -c 'kill -9 $$'
> Checking ./199.mkstemp

Hmm.  My attempted workaround pollutes stderr on some setups, thus
causing this failure, even though I had not encountered it on any of
the platforms I tested before the release.  I'll fix it for m4 1.4.20,
but in the meantime, you can ignore the failure and use the build (the
bug is in the testsuite, not in the built binary).

> 
> When I run the commands from the terminal that you suggested in the previous
> message, I get this:
> 
> ```
> [Bubble:~] nieder $ /bin/sh -c '/bin/sh -c "kill 9 \$\$"; echo $?'

My bad; I missed the '-9' instead of '9' in that suggested command.

> /bin/sh: line 0: kill: (9) - No such process
> /bin/sh: line 1: 41099 Terminated: 15  /bin/sh -c "kill 9 \$\$"
> 143
> [Bubble:~] nieder $ (SHELL=ksh; $SHELL -c "$SHELL"' -c "kill -9 \$\$"
> 2>/dev/null; echo $?')
> ksh: 41102: Killed
> 265
> ```
> 
> Hanspeter
> 

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3266
Virtualization:  qemu.org | libvirt.org

Re: [m4-1.4.19] make error on Solaris 11.3 x86

[Eric Blake]

On Sat, May 29, 2021 at 08:33:08AM +0900, Kiyoshi KANAZAWA wrote:
> Hello,
> 
> Trying to install m4-1.4.19 on Solaris 11.3 x86.
> 
> $ uname -a
> SunOS hidden 5.11 11.3 i86pc i386 i86pc
> 
> $ gcc --version
> gcc (GCC) 10.3.0
> 
> $ ./configure CC=gcc
> (it mean CC='gcc -m32')
> 
> $ make
>    :
>   CC   stackvma.o
> In file included from stackvma.c:1476:
> /usr/include/sys/procfs.h:42:2: error: #error "Cannot use procfs in the large 
> file compilation environment"
>    42 | #error "Cannot use procfs in the large file compilation environment"
> 
> This did not occur in m4-1.4.18d.

Thanks for the report; this is probably due to Bruno's work on making
gnulib support stack overflow detection without GNU libsigsegv on more
platforms, so I hope he'll be able to help.

> 
> FYI:
> /usr/include/sys/procfs.h:
> 41  #if !defined(_LP64) && _FILE_OFFSET_BITS == 64
> 42  #error  "Cannot use procfs in the large file compilation environment"
> 43  #endif
> 
> 
> Regards,
> 
> --- Kiyoshi
> 
> 

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3266
Virtualization:  qemu.org | libvirt.org

Re: m4 on native Windows

[Eric Blake]

On Wed, May 26, 2021 at 08:52:51AM -0500, Eric Blake wrote:
> > +++ m4-tmp.432/m4-err   2021-05-14 02:31:09.296595600 +0200
> > @@ -1,2 +1,2 @@
> > -C:\cygwin64\home\bruno\m4-2021-05-13\build-mingw64\src\m4.exe:stdin:1: 
> > Warning: too few arguments to builtin `index'
> > -C:\cygwin64\home\bruno\m4-2021-05-13\build-mingw64\src\m4.exe:stdin:3: 
> > Warning: excess arguments to builtin `index' ignored
> > +m4.exe:stdin:1: Warning: too few arguments to builtin `index'
> > +m4.exe:stdin:3: Warning: excess arguments to builtin `index' ignored
> 
> Failures like this look like we just need to fix the sed script in
> checks/check-them to properly filter the name output by native
> Windows.

I'm still trying to figure out how the names differ.  Can you confirm
what is output by:
  src/m4 --help | head -n1

in that setup?  That output comes from usage() which uses program_name
directly, while the other messages come from calling error_at_line()
which uses program_invocation_name (on glibc) or getprogname()
(otherwise), but as far as I can tell, unless we are running under
libtool (where getprogname() strips off the lt- prefix), that should
resolve to the same program_name as just printed in usage().  So what
is going on differently in your native windows build that is changing
what error_at_line() produces?

At this point, I'm probably going to just go ahead and release 1.4.19
without trying to address the Windows testsuite failures.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3266
Virtualization:  qemu.org | libvirt.org

[PATCH] tests: Skip signal detection on Haiku

[Eric Blake]

On Haiku, using 'kill -9' fromm /bin/shactually causes a process to
die with the non-standard SIGKILLTHR 15, which causes 198.sysval to
fail from the unexpected value.

* doc/m4.texi (Sysval): Skip test on Haiku.
Reported by Bruno Haible,
https://lists.gnu.org/archive/html/bug-m4/2021-05/msg4.html
---
 doc/m4.texi | 14 +++---
 1 file changed, 11 insertions(+), 3 deletions(-)

diff --git a/doc/m4.texi b/doc/m4.texi
index 7dcbb5ce..94ac851d 100644
--- a/doc/m4.texi
+++ b/doc/m4.texi
@@ -6745,14 +6745,22 @@ Sysval
 @comment systems where /bin/sh does not create its own process group.
 @comment And PIPE is unreliable, since people tend to run with it
 @comment ignored, with m4 inheriting that choice.  That leaves KILL as
-@comment the only signal we can reliably test.
+@comment the only signal we can reliably test, but even that is tricky:
+@comment on Haiku, 'kill -9' actually causes a process to die with
+@comment signal 15 named KILLTHR on that platform.
 @example
 dnl This test assumes kill is a shell builtin, and that signals are
 dnl recognizable.
 ifdef(`__unix__', ,
   `errprint(` skipping: syscmd does not have unix semantics
 ')m4exit(`77')')dnl
-syscmd(`kill -9 $$')
+changequote(`[', `]')
+@result{}
+syscmd([/bin/sh -c 'kill -9 $$'; st=$?; test $st = 137 || test $st = 265])
+@result{}
+ifelse(sysval, [0], , [errprint([ skipping: shell does not send signal 9
+])m4exit([77])])dnl
+syscmd([kill -9 $$])
 @result{}
 sysval
 @result{}2304
@@ -6760,7 +6768,7 @@ Sysval
 @result{}
 sysval
 @result{}0
-esyscmd(`kill -9 $$')
+esyscmd([kill -9 $$])
 @result{}
 sysval
 @result{}2304
-- 
2.31.1

Re: Bug

[Eric Blake]

On Sun, Feb 07, 2021 at 03:48:59PM +0400, Ilia Chachanidze wrote:
> configure: WARNING: sys/bitypes.h: present but cannot be compiled
> configure: WARNING: sys/bitypes.h: check for missing prerequisite
> headers?
> configure: WARNING: sys/bitypes.h: see the Autoconf documentation
> configure: WARNING: sys/bitypes.h: section "Present But Cannot Be
> Compiled"
> configure: WARNING: sys/bitypes.h: proceeding with the compiler's result
> configure: WARNING: ## - ##
> configure: WARNING: ## Report this to bug-m4@gnu.org ##
> configure: WARNING: ## - ##

Thanks for the report; however, I need more details before I have
anything that can be acted on.  What platform were you on, and what
tarball were you trying to build?  Also, do you have the associated
section of config.log that shows the actual failure encountered during
that part of configure?  I'm hoping to release 1.4.19 this month, and
am hoping that you merely encountered something present in an older
tarball that is no longer a problem in the current m4.git.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3266
Virtualization:  qemu.org | libvirt.org

Re: --synclines adds #line 4711 after #define xyz(abc) ...\

[Eric Blake]

On Sat, Dec 26, 2020 at 06:26:42PM +, Kadlec, Albrecht wrote:
> Hi,
> 
> We are using GNU m4 1.4.18:  are there any plans for extensions a'la a c-mode 
> via
> -synclines=c,'#line __line__ "__file__"'
> (also defining the lead-in per file) to add line-continuation awareness and 
> maybe even comment awareness ?
> Or a function
> syncline(`#line '__line__ "__file__")
> to enable switching on/off/changing the syntax?
> Do you accept up-streaming contributions? -> next deadline/release?

Contributions are okay if you are willing to assign copyright to the
FSF; however, I must be fair and warn you that a contribution to teach
m4 how to report dependency tracking more like gcc has now stalled for
several years, because there has been very little active development
on m4.

Adding new macros must be done carefully (we don't want to break
existing use of m4 where the new macro name had other purposes).
Also, POSIX is fairly vague at what synclines do, stating only:

> The following options shall be supported:
> 
> -s
> Enable line synchronization output for the c99 preprocessor phase (that 
> is, #line directives).
[https://pubs.opengroup.org/onlinepubs/9699919799/utilities/m4.html]

with no mention of what format those lines must take (either on the
description for m4, or for c99).  But changing their output is also a
risk if it is not done as an opt-in manner, so figuring out how to
opt-in (or even if opting in is possible for a given build of m4)
needs to be thought about.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3266
Virtualization:  qemu.org | libvirt.org

Re: Enable more single-thread optimizations in gnulib code

[Eric Blake]

On Thu, May 13, 2021 at 11:25:41AM +0200, Bruno Haible wrote:
> According to the Gnulib documentation section "Optimizations of multithreaded
> code" several more optimizations can be enabled. This patch
>   - enables these single-threading optimizations,
>   - by doing so, gets rid of the warnings in regex.c,
>   - causes no test failures.
> 
> OK to push?
>

Thanks; pushed.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3266
Virtualization:  qemu.org | libvirt.org

Re: m4 on native Windows

[Eric Blake]

On Fri, May 14, 2021 at 12:58:18PM +0200, Bruno Haible wrote:
> Compiling a recent m4 snapshot on native Windows:
>   - The "make" step works fine.
>   - The "make check" step fails. Find attached the log.
> 
> Essentially, there are failures around syscmd, and error messages display
> the absolute file name of the 'm4.exe' executable.

Thanks for the report.  I'll see if I can fine-tune any of these
tests, but the failures are in the testsuite and not the built
executable, so I'm okay with releasing even if these still fail.

> Checking ../../checks/021.macro_argu
> @ ../doc/m4.texi:1607: Origin of test
> ../../checks/021.macro_argu: stderr mismatch
> --- m4-tmp.432/m4-xerr2021-05-14 02:31:09.407442400 +0200
> +++ m4-tmp.432/m4-err 2021-05-14 02:31:09.296595600 +0200
> @@ -1,2 +1,2 @@
> -C:\cygwin64\home\bruno\m4-2021-05-13\build-mingw64\src\m4.exe:stdin:1: 
> Warning: too few arguments to builtin `index'
> -C:\cygwin64\home\bruno\m4-2021-05-13\build-mingw64\src\m4.exe:stdin:3: 
> Warning: excess arguments to builtin `index' ignored
> +m4.exe:stdin:1: Warning: too few arguments to builtin `index'
> +m4.exe:stdin:3: Warning: excess arguments to builtin `index' ignored

Failures like this look like we just need to fix the sed script in
checks/check-them to properly filter the name output by native
Windows.

> Checking ../../checks/194.syscmd
> @ ../doc/m4.texi:6592: Origin of test
> ../../checks/194.syscmd: stdout mismatch
> --- m4-tmp.432/m4-xout2021-05-14 02:37:05.500248600 +0200
> +++ m4-tmp.432/m4-out 2021-05-14 02:37:05.298096600 +0200
> @@ -1,3 +1,2 @@
>  
> -foo
>  
> @ ../doc/m4.texi:6592: Origin of test
> ../../checks/194.syscmd: stderr mismatch
> --- m4-tmp.432/m4-xerr2021-05-14 02:37:05.875718100 +0200
> +++ m4-tmp.432/m4-err 2021-05-14 02:37:05.735120300 +0200
> @@ -0,0 +1,2 @@
> +m4.exe: syscmd subprocess failed: No such file or directory
> +m4.exe:stdin:2: cannot run command `echo foo': No such file or directory

These will indeed be hairier to fix, especially since it has now been
a long time since I've used a Windows machine.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3266
Virtualization:  qemu.org | libvirt.org

Re: test failure on Haiku

[Eric Blake]

On Mon, May 10, 2021 at 01:28:44AM +0200, Bruno Haible wrote:
> On Haiku (32-bit), compiling m4-1.4.18b+fixes works fine, but one of the tests
> fails:
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Checking ../../checks/198.sysval
> @ ../doc/m4.texi:6749: Origin of test
> ../../checks/198.sysval: stdout mismatch
> --- m4-tmp.10743/m4-xout  2021-05-10 01:15:42.526647296 +
> +++ m4-tmp.10743/m4-out   2021-05-10 01:15:42.504102912 +
> @@ -1,6 +1,6 @@
>  
> -2304
> +5376
>  
>  0
>  
> -2304
> +5376
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> 
> 2304 is 0x0900, whereas 5376 is 0x1500.
> 
> On this platform, the signal number 0x09 is SIGKILL, and the signal
> number 0x15 is SIGKILLTHR. I can reproduce it also in the shell:
> When you kill a process with signal 9, bash reports not "Killed"
> but "Kill Thread", and 'echo $?' prints not 137 but 149.

Thanks for the report.  The test already acknowledges that testing
sysval is inherently difficult:

@comment This test has difficulties being portable, even on platforms
@comment where syscmd invokes /bin/sh.  Kill is not portable with signal
@comment names.  According to autoconf, the only portable signal numbers
@comment are 1 (HUP), 2 (INT), 9 (KILL), 13 (PIPE) and 15 (TERM).  But
@comment all shells handle SIGINT, and ksh handles HUP (as in, the shell
@comment exits normally rather than letting the signal terminate it).
@comment Also, TERM is flaky, as it can also kill the running m4 on
@comment systems where /bin/sh does not create its own process group.
@comment And PIPE is unreliable, since people tend to run with it
@comment ignored, with m4 inheriting that choice.  That leaves KILL as
@comment the only signal we can reliably test.
@example
dnl This test assumes kill is a shell builtin, and that signals are
dnl recognizable.
ifdef(`__unix__', ,
  `errprint(` skipping: syscmd does not have unix semantics
')m4exit(`77')')dnl

I suppose our only recourse is to figure out a way to skip the test on
Haiku by testing whether kill -9 actually results in signal 9 from the
shell's perspective, prior to attempting it from m4's perspective.
What does this output for you on the affected platform?

$ /bin/sh -c '/bin/sh -c "kill 9 \$\$"; echo $?'
$ (SHELL=ksh; $SHELL -c "$SHELL"' -c "kill -9 \$\$" 2>/dev/null; echo $?')

It is 137 (bash, most other shells) or 265 (ksh) on GNU/Linux (and
presumably all other systems that don't have SIGKILLTHR); I'm guessing
that for you it will output 143.  If so, I can then enhance the test
to test what shell death will report prior to testing what m4 sees
from shell death.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3266
Virtualization:  qemu.org | libvirt.org

Re: [m4] The source code has been broken for years

[Eric Blake]

Revisiting an older thread,

On 9/12/20 10:15 PM, Michael Witten wrote:

> I see now that the home page (https://www.gnu.org/software/m4/) does indeed
> inform the user to checkout that particular branch:
> 
>   git checkout -b branch-1.4 origin/branch-1.4
> 
> I had a really old repo in which I just ran 'git pull', and so I did not
> know better.
> 
> Is the 'master' branch intended to be abandoned? If so:
> 
>   * Maybe it would be worthwhile to point 'master' to a commit that offers
> nothing but a 'README' explaining the abandonment.

Now done (experimental 2.0 code is now in branch-2.0 instead).

I'm also wondering if I should take this opportunity to change 'master'
to 'main'; thoughts?

> 
>   * Perhaps 'git config' offers some help. The variable 'transfer.hideRefs'
> looks like it might be worth investigating, but I'm not certain.
> 
>   * Run the following in the bare repository; it should help the user out
> by informing 'git clone' which branch to set up as the default:
> 
>   $ git symbolic-ref HEAD refs/heads/branch-1.4

I don't know if I have access to Savannah's bare repository storage.


-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3226
Virtualization:  qemu.org | libvirt.org

Re: SIGSTKSZ is now a run-time variable

[Eric Blake]

On 3/4/21 8:34 AM, Carol Bouchard wrote:
> M4 Maintainers:
> 
> I work on a test system for distro testing.  I need to build newer Fedora
> images
> before they are released to public.  A change that was introduced is the
> #define SIGSTKSZ is no longer a statically defined variable.  It's value can
> only be determined at run time.
> 
> # define SIGSTKSZ sysconf (_SC_SIGSTKSZ)
> 
> This affects m4 code since the code assumes a statically defined variable
> which
> can be determined at preprocessor time.  As a result, the m4 code no longer
> compiles.
> 
> /usr/include/signal.h:315,
>  from ./signal.h:52,
>  from c-stack.c:49:
> c-stack.c:55:26: error: missing binary operator before token "("
>55 | #elif HAVE_LIBSIGSEGV && SIGSTKSZ < 16384
>   |  ^~~~
> I am using m4-1.4.18 with compiler gcc (GCC) 10.2.1 20201125 (Red Hat
> 10.2.1-9).
> Please advise how I can get past this.  It doesn't look like a simple
> change.  Do you
> already have a patch available for this?

Bringing some closure to this thread:

Gnulib commit f9e2b20a12 (Sep 2020) fixed the use of SIGSTKSZ, and now
that latest m4.git uses newer gnulib, I have finished testing that I can
once again build m4 1.4.x on Rawhide without error, whether or not
libsigsegv is installed.

I hope to release m4 1.4.19 soon.


-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3226
Virtualization:  qemu.org | libvirt.org

Poor hashtable collision performance

[Eric Blake]

Consider the following program I wrote to divide a 50,000 byte string
into a stack of one character per definition (this is supposed to be an
O(n log n) task, because it repeatedly cuts the input in half, and
should be more efficient than iterating on
substr(`$1',0,1)$0(substr(`$1',1) with its O(n^2) complexity):

$ cat tmp
define(`chew', `ifelse($1, 1, `pushdef(`stack', substr(`$2',0, 1))',
  `$0(eval($1/2), substr(`$2', 0, eval($1/2))_)$0(eval($1 - $1/2),
  substr(`$2', eval($1/2)))')')dnl
chew(5, format(`%05d', 0))dnl
$ time m4 tmp

real0m22.264s
user0m22.180s
sys 0m0.010s
$ time m4 -H517 tmp

real0m0.321s
user0m0.316s
sys 0m0.004s

What gives?  It turns out that with the default hash size of 509,
'stack' and 'substr' hash to the same bucket, and as the pushdef depth
of stack increases, the lookup time for 'substr' gets progressively
worse.  With -H517, the two names hash to different buckets and no
longer interfere.  I'm working on a patch to separate the pushdef chain
from the hash bucket chain, so that hash collisions only have to visit
one instance of a colliding name, not the entire stack.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3226
Virtualization:  qemu.org | libvirt.org

Re: SIGSTKSZ is now a run-time variable

[Eric Blake]

On 3/9/21 1:34 PM, Eric Blake via austin-group-l at The Open Group wrote:
> On 3/9/21 10:14 AM, shwaresyst wrote:
>>
>> To me that looks like a conformance violation and should be reverted. There 
>> is no _SC_SIGSTKSZ defined in  by the standard, to begin with, so 
>> that use of sysconf() is a non-portable extension on its own.
> 
> Portable apps can't use _SC_SIGSTKSZ, but the standard generally permits
> implementations to define further constants.  Then again, re-reading XSH
> 2.2.2:
> 
> " Implementations may add symbols to the headers shown in the following
> table, provided the identifiers for those symbols either:
> 
> Begin with the corresponding reserved prefixes in the table, or
> ..."
> 
> but the table lacks a row for  with _CS_* and _SC_* constants.
>  Looks like you found an independent defect.

Not quite, because later it states "The following identifiers are
reserved regardless of the inclusion of headers: 1. With the exception
of identifiers beginning with the prefix _POSIX_, all identifiers that
begin with an  and either an uppercase letter or another
 are always reserved for any use by the implementation.", so
an implementation can blindly add _SC_* constants at will without
violating the standard.

Still, I opened:
https://www.austingroupbugs.net/view.php?id=1456
to try and add some clarification.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3226
Virtualization:  qemu.org | libvirt.org

Re: SIGSTKSZ is now a run-time variable

[Eric Blake]

On 3/9/21 10:14 AM, shwaresyst wrote:
> 
> To me that looks like a conformance violation and should be reverted. There 
> is no _SC_SIGSTKSZ defined in  by the standard, to begin with, so 
> that use of sysconf() is a non-portable extension on its own.

Portable apps can't use _SC_SIGSTKSZ, but the standard generally permits
implementations to define further constants.  Then again, re-reading XSH
2.2.2:

" Implementations may add symbols to the headers shown in the following
table, provided the identifiers for those symbols either:

Begin with the corresponding reserved prefixes in the table, or
..."

but the table lacks a row for  with _CS_* and _SC_* constants.
 Looks like you found an independent defect.

> 
> I could see the definition of SIGSTKSZ being changed to the static minimum a 
> particular processor requires, or is initially allocated as a 'safe' amount, 
> rather than static "default size", and moving SIGSTKSZ to . This 
> would contrast to MINSIGSTKSZ as the lowest value for a platform for all 
> supported processors. Then an application could use sysconf() to query for 
> the maximum size the configuration supports if it wants to use more than 
> that, as a runtime increasable limit.

As I understand it, the concern in glibc is less about runtime
increasability, so much as ABI compatibility with applications compiled
against older headers at a time when the kernel had less state
information to store during a context switch.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3226
Virtualization:  qemu.org | libvirt.org

Re: SIGSTKSZ is now a run-time variable

[Eric Blake]

[adding bug-gnulib]

On 3/6/21 12:50 PM, Bruno Haible wrote:
> Hi,
> 
> Carol Bouchard wrote in 
> <https://lists.gnu.org/archive/html/bug-m4/2021-03/msg0.html>:
>> A change that was introduced is the
>> #define SIGSTKSZ is no longer a statically defined variable.  It's value can
>> only be determined at run time.
>>
>> # define SIGSTKSZ sysconf (_SC_SIGSTKSZ)
> 
> This is invalid. POSIX:2018 [1] defines two lists of macros:
> 
>   1) "The  header shall define the following macros which shall
>   expand to integer constant expressions that need not be usable in
>   #if preprocessing directives:"
> 
>   2) "The  header shall also define the following symbolic 
> constants:"
> 
> SIGSTKSZ is in the second list. This implies that it must expand to a constant
> and that it must be usable in #if preprocessing directives.
> 
> Besides being invalid, it is also not needed. The alternate signal stack
> needs to be dimensioned according to the CPU and ABI that is in use. For 
> example,
> SPARC processors tend to use much more stack space than x86 per function
> invocation. Similarly, 64-bit execution on a bi-arch CPU tends to use more 
> stack
> space than 32-bit execution, because return addresses and other pointers are
> 64-bit vs. 32-bit large. But once you have fixed the CPU and the ABI, there is
> no ambiguity any more.
> 
>> This affects m4 code since the code assumes a statically defined variable 
>> which
>> can be determined at preprocessor time.
> 
> POSIX guarantees this assumption.

Only when sticking strictly to POSIX.  Reading the glibc NEWS more closely,

* Add _SC_MINSIGSTKSZ and _SC_SIGSTKSZ.  When _SC_SIGSTKSZ_SOURCE or
  _GNU_SOURCE are defined, MINSIGSTKSZ and SIGSTKSZ are no longer
  constant on Linux.  MINSIGSTKSZ is redefined to sysconf(_SC_MINSIGSTKSZ)
  and SIGSTKSZ is redefined to sysconf (_SC_SIGSTKSZ).

which means you only have a non-constant SIGSTKSZ when _explicitly_
asking for non-POSIX extensions by setting _GNU_SOURCE; but since most
gnulib projects (including m4) indeed request _GNU_SOURCE, we can no
longer rely on the POSIX definition.

> 
>> Please advise how I can get past this.
> 
> Fix your .

We're going to need to fix gnulib instead, and then release an updated
m4 built with a newer gnulib.

> 
> Bruno
> 
> [1] https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/signal.h.html
> 
> 

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3226
Virtualization:  qemu.org | libvirt.org

Re: SIGSTKSZ is now a run-time variable

[Eric Blake]

[adding glibc and Austin group lists]

On 3/6/21 12:50 PM, Bruno Haible wrote:
> Hi,
> 
> Carol Bouchard wrote in 
> <https://lists.gnu.org/archive/html/bug-m4/2021-03/msg0.html>:
>> A change that was introduced is the
>> #define SIGSTKSZ is no longer a statically defined variable.  It's value can
>> only be determined at run time.
>>
>> # define SIGSTKSZ sysconf (_SC_SIGSTKSZ)
> 
> This is invalid. POSIX:2018 [1] defines two lists of macros:
> 
>   1) "The  header shall define the following macros which shall
>   expand to integer constant expressions that need not be usable in
>   #if preprocessing directives:"
> 
>   2) "The  header shall also define the following symbolic 
> constants:"
> 
> SIGSTKSZ is in the second list. This implies that it must expand to a constant
> and that it must be usable in #if preprocessing directives.

The question becomes whether glibc is in violation of POSIX for having
made the change, or whether POSIX needs to be amended to allow SIGSTKSZ
to be non-preprocessor-safe and/or non-constant.

> 
> Besides being invalid, it is also not needed. The alternate signal stack
> needs to be dimensioned according to the CPU and ABI that is in use. For 
> example,
> SPARC processors tend to use much more stack space than x86 per function
> invocation. Similarly, 64-bit execution on a bi-arch CPU tends to use more 
> stack
> space than 32-bit execution, because return addresses and other pointers are
> 64-bit vs. 32-bit large. But once you have fixed the CPU and the ABI, there is
> no ambiguity any more.
> 
>> This affects m4 code since the code assumes a statically defined variable 
>> which
>> can be determined at preprocessor time.
> 
> POSIX guarantees this assumption.
> 
>> Please advise how I can get past this.
> 
> Fix your .

https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=6c57d320484988e87e446e2e60ce42816bf51d53
shows where glibc made the change, and I've now seen reports of several
projects failing to build when using glibc with this change included.

> 
> Bruno
> 
> [1] https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/signal.h.html
> 
> 

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3226
Virtualization:  qemu.org | libvirt.org

Re: Memory exhausted error

[Eric Blake]

On 12/16/20 10:27 PM, lexxmark@gmail.com wrote:
> I’m porting flex/bison on windows and build M4 code inside executable.
> 
> After upgrading gnulibs I caught a runtime error “memory exhausted” in 
> macro.c file.

What do you mean by updating gnulib, pointing the submodule to a newer
commit?  Yes, there have been a number of changes in more recent gnulib
that may require some porting efforts in the matching m4 code to follow
new semantics from what gnulib offers, and it looks like you have found
one of them.


> 
>obstack_blank (_stack, -argc * sizeof (token_data *)); << crash 
> here!!! 
> Line 390
> 
> }
> 
> It seems now obstack_blank function doesn’t allow negative numbers (see 
> /lib/obstack.h file)

That matches gnulib/NEWS for 2014-10-29; the fix is to use
obstack_blank_fast() instead, when using a gnulib newer than that date.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3226
Virtualization:  qemu.org | libvirt.org

Re: BUG PROBLEM-> recursive macro inplace substitution

[Eric Blake]

On 9/30/20 5:03 AM, hhmm wrote:
> please see this reference
> 
> https://stackoverflow.com/questions/64066166/how-to-rescan-m4-data-for-recursive-macro-inplace-substitution/64066869?noredirect=1#comment113299085_64066869

Better yet, ask your question directly here, instead of making every
reader chase a URL that may have a different lifetime than the mailing
list archive.

So doing that on your behalf:

> I have this very simple code.
> 
> define(`S',`some')
> define(`T',`thing')
> define(`something',`st_todo') 
> S`'T 

In the interim, this expands to:
some`'thing

and thus the scanner never gets to see "something" as a single macro name.

> OR 
> S()T() 

Partway through evaluation, this has expanded to:

someT()

but someT is not a macro name, and thus the scanner never gets to see
"something" as a single macro name.

> 
> the actual end result is
> 
> something 
> OR 
> something 

You probably meant "someT()" here, based on your examples above.

> 
> but expected recursive substitution result as
> 
> st_todo
> 
> how I can rescan the code to the input again ?

The existing answers on that topic appear to gracefully cover it: any
time you want a second macro to be expanded and that expansion
concatenated with the output of the first, for evaluating the entire
concatenation for further macros, you have to use a glue macro.

define(`concat',`$1$2')
concat(S,T)

evaluates to:

concat(`some',`thing')

which in turn evaluates to:

something

which is now a valid macro name, and finally expands to:

st_todo

If you need a macro that concatenates more than just $1 and $2, you can
write it.
https://www.gnu.org/software/m4/manual/m4-1.4.15/html_node/Shift.html#index-joining-arguments-130
documents a "join" macro shipped with the m4 documentation that can be
used with an empty separator to concatenate an arbitrary number of
arguments into a single-quoted string with no intervening `' or (); pass
that through one more macro call to perform macro expansion on the
entire string.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3226
Virtualization:  qemu.org | libvirt.org



signature.asc
Description: OpenPGP digital signature

Re: Build failure m4

[Eric Blake]

On 8/31/20 11:16 AM, Neal Schweighart wrote:

Hello,

I am running into an error whenever I try to run autoconf when building 
casatools on my redhat machine. It is giving me a message that says Disk 
quota is being exceeded for the /usr/bin/m4 director. Here is the full 
error message:



sazed_nschweig<1012> autoconf
/usr/bin/m4: cannot clean temporary file for diversion: Disk quota exceeded
*** Error in `/usr/bin/m4': double free or corruption (!prev): 


Thank you for the report. It looks like you have stumbled on an 
infrequently tested path, and looks like the error recovery mechanism in 
m4 has a bug when encountering low disk space due to a quota.


As for completing your build, you'll have to find a way to enlarge the 
quota.  In the meantime, we'll have to figure out what the actual bug is 
in the m4 error recovery code and repair it before the next m4 version 
is released.


--
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3226
Virtualization:  qemu.org | libvirt.org

Re: regexp curly braces do not work

[Eric Blake]

On 7/30/20 1:24 AM, Hyunho Cho wrote:

m4 (GNU M4) 1.4.18
Operating System: Ubuntu 20.04 LTS
Kernel: Linux 5.4.0-33-generic
Architecture: x86-64


sh$ m4 <<\@
patsubst(`hello', `ll', `XX')
patsubst(`hello', `l+', `XX')
patsubst(`hello', `l\{2\}', `XX')
patsubst(`hello', `l{2}', `XX')
@
heXXo
heXXo
hello
hello


Unfortunately correct for m4 1.4.  The source code uses GNU regex.h, and 
does not bother to modify re_syntax or call re_set_syntax(), which means 
m4 defaults to RE_SYNTAX_EMACS (ie. all regex bits set to 0).  Looking 
at the various bits that can be set for re_syntax,


/* If this bit is set, either \{...\} or {...} defines an
 interval, depending on RE_NO_BK_BRACES.
   If not set, \{, \}, {, and } are literals.  */
# define RE_INTERVALS (RE_HAT_LISTS_NOT_NEWLINE << 1)

and since m4 isn't doing anything about that bit, no form of {} works.

At some point, a future m4 release will add the ability to set regex 
flavors (emacs, POSIX BRE, POSIX ERE, etc), and depending on the flavor 
chosen, either {} or \{\} will work.  But until that release happens, 
you are stuck with the existing m4 being limited in expressive power.


--
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3226
Virtualization:  qemu.org | libvirt.org

Re: Trouble with m4 on linux

[Eric Blake]

On 7/17/20 7:57 PM, M.R.P. zensky wrote:

Hello I am on linux. M4 is installed. I try to define a macro in M4 by typing 
M4 —define (test,Hello)  I just get the message “bash: syntax error near 
unexpected token `(`   Do I need to install or setup some other program than m4 
for it to work? What am I doing wrong?


Are you trying to define the macro 'test' to expand to the contents 
'Hello' from the command line?  If so, that would be done as:


$ m4 --define test=Hello

Or, if you are trying to define it while in m4:

$ m4
define(`test', `Hello')

On the command line, you have to abide by bash's syntax (such as proper 
shell quoting for anything that would otherwise confuse the shell, such 
as bare '(') and the fact that definitions on the command line are not 
spelled the same as macro expansions within m4 proper, but are rather 
name=value arguments (if you are familiar with 'make', that's another 
program that has similar command-line syntax).


--
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3226
Virtualization:  qemu.org | libvirt.org

Re: error on using $# and m4wrap

[Eric Blake]

On 7/26/20 9:12 AM, Hyunho Cho wrote:

m4 (GNU M4) 1.4.18
Operating System: Ubuntu 20.04 LTS
Kernel: Linux 5.4.0-33-generic
Architecture: x86-64

### 1. if i define $# as macro body then error occurred

$ m4 <<\@
define(`foo', $2)
foo(100,200,300)
@

200  # OK
-

$ m4 <<\@
define(`foo', $#)
foo(100,200,300)
@
m4:stdin:1: ERROR: end of file in argument list


That is expected behavior.  Any unquoted # starts a comment, and the 
comment doesn't end until newline.  The ) you placed in the comment is 
therefore not recognized as the end of the define macro call, hence m4 
errors out that you ended input in the middle of a macro call.



---

$ m4 <<\@
define(`foo', `$#') # must quote `$#'
foo(100,200,300)
@

3# OK


And yes, this is the correct solution to that issue.



###

### 2. if i invocate m4wrap just once then return macro body

$ m4 <<\@
define(`foo', 1)dnl
define(`bar', 2)dnl
define(`zoo', 3)dnl
m4wrap(`zoo')dnl
9
@
9
3  < not zoo but 3


This is correct behavior.  When reaching end of input, all wrapped code 
is concatenated and expanded, and all you have collected is 'zoo' which 
is a macro name, so it is expanded.




$ m4 <<\@
define(`foo', 1)dnl
define(`bar', 2)dnl
define(`zoo', 3)dnl
m4wrap(`foo')dnl
m4wrap(`bar')dnl
m4wrap(`zoo')dnl
9
@
9
zoobarfoo


This is also correct behavior.  The concatenated text is zoobarfoo, 
which is not a macro name, and therefore output as-is.  If you want to 
guarantee that each m4wrap is viewed as code in isolation, the easiest 
way is to insert empty quotes at the conclusion of each text you wrap:


$ m4 <<\@
define(`foo', 1)dnl
define(`bar', 2)dnl
define(`zoo', 3)dnl
m4wrap(`foo`'')dnl
m4wrap(`bar`'')dnl
m4wrap(`zoo`'')dnl
9
@
9
321

because the resulting concatenated wrapped text is now zoo`'bar`'foo`', 
which indeed has three recognized macros.


I don't see any bug in the behavior you have reported.

--
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3226
Virtualization:  qemu.org | libvirt.org

Re: Minor documentation bug: license section numbering

[Eric Blake]

[adding bug-texinfo]

On 2/22/20 5:24 AM, Aa 123456789 wrote:

Good evening,

I was reading the m4 documentation you have posted at
https://www.gnu.org/savannah-checkouts/gnu/m4/manual/m4-1.4.18/m4.html,
and I noticed that there's a very minor bug with the included copy of
the GPLv3 (in appendix A). The original GPLv3 text numbers its
sections starting from 0, but your copy uses 1-based numbering,
causing all cross-references to other sections to be off by one. (For
instance, "You may convey a covered work in object code form under the
terms of sections 4 and 5" at the beginning of the "Conveying
Non-Source Forms" section should actually reference sections 5 and 6
by your renumbering.)
The GFDL in appendix B also uses 1-based numbering, but I'm not
familiar with it enough to determine if there are any similar
off-by-one errors or not.


Thanks for the report.  Both appendices are generated via verbatim 
inclusion of pre-existing .texi files from upstream, and a quick scan of 
both documents shows that they use '@enumerate 0' prior to the headings 
in question.  The html rendering is generated with 'makeinfo'.


The effect that you are seeing is not limited to m4; I see the same 
1-based html rendering in the coreutils manual, for example:

https://www.gnu.org/savannah-checkouts/gnu/coreutils/manual/coreutils.html#GNU-Free-Documentation-License
shows "1. PREAMBLE", but
info coreutils 'GNU Free Documentation License'
shows "0. PREAMBLE"

So this smells like a makeinfo bug, in that it is unable to properly 
render @enumerate 0 into something that adjusts the html rendering.  But 
it also looks like a bug that was fixed recently, because when I do 
'make -C doc html' locally with texinfo 6.6 installed (on Fedora 31), 
the html output is different: the online page used , but my local 
page used .  So all that really remains is to release m4 
1.4.19 with updated gnulib dependencies (needed anyways), where the 
release process will trigger a rebuild of the web pages with newer 
makeinfo, such that the resulting web page will then have correct numbering.


--
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3226
Virtualization:  qemu.org | libvirt.org

Re: Checks in m4 and different format of error messages

[Eric Blake]

[moving to the public mailing list with permission]

On 2/18/20 9:01 AM, Mikhail Sviridov wrote:

Hi Gary, Eric

I'm not sure if there is any possibility to specify a pattern instead of
fixed text in the following line of checks/137.include and many other files
there:
dnl @error{}m4:stdin:1: cannot open `none': No such file or directory

because in our system we have a different format of the message:

cannot open `none': EDC5129I No such file or directory. (errno2=0x05620062)

The first solution that comes to mind is to change the error message under
@error macro, but is there any crossplatform way to do that or specify a
pattern instead of fixed text?


You didn't mention what system this is on.

If you'll look at the script checks/check-them, you will see that the 
testsuite already does some post-processing filtering on the actual m4 
output to move it into a form that it can be compared against the 
expected output embedded in the tests themselves (for example, look at 
the setting and use of the $m4name variable).  It sounds like your 
system's strerror() output (with the extra "EDC5129I" and 
"(errno2=0x05620062)" information) would be the perfect candidate for 
adding yet another filter to that script.


Patches are welcome.

--
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3226
Virtualization:  qemu.org | libvirt.org

Re: Bug math.h?

[Eric Blake]

On 2/3/20 8:02 AM, Arthur Armand wrote:

Hello

This is my screen error...

[image: image.png]


Attaching an image is poor use of bandwidth (the mail server has to 
replicate the image to every subscriber, and some subscribers may have 
data limits that make downloading an image expensive); if an image is 
needed, it is better to just post a URL to the image hosted elsewhere 
(then only interested subscribers have to chase the link), or even 
better to just paste the text from your terminal instead of relying on a 
screenshot.


Transcribing relevant portions of what I see in the image:

$ make
C:/Apache/Git/mingw64/bin/make.exe  all-recursive
...
make[2]: Entering directory 'C:/Apache/httpd-2.4.41//srclib/m4-1.4.18/lib'
...
  GEN  locale.h
/usr/bin/sh: -c: line 212: unexpected EOF while looking for matching `''
/usr/bin/sh: -c: line 213: syntax error: unexpected end of file
make[2]: *** [Makefile:2400: math.h] Error 1
...



Could you help me?



I haven't personally tried to build m4 under mingw, so it could be 
something about the mingw platform that is tripping you up (perhaps a 
stray carriage return somewhere confusing sh?).  So I'm not sure how 
best to proceed with debugging this build failure further.  The problem 
is probably not in math.h directly, but in the Makefile and shell code 
injected by gnulib's math module during autoconf/automake.  Perhaps you 
can try to find what portion of the generated 'configure' file is 
probing for math.h, or what gets inserted into the Makefile at the point 
where make tries to run /usr/bin/sh -c on a sed script that would 
generate math.h.


--
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3226
Virtualization:  qemu.org | libvirt.org

Re: m4 1.4.18 fails immediately when run on Mac

[Eric Blake]

On 11/22/19 12:59 PM, Vanessa McHale wrote:

Hi all,

When I try to run m4 on my Mac, it immediately fails with

Abort trap: 6


Can you get a backtrace of where the abort() call is happening?  I don't 
have access to a Mac, so I am not in a position to easily reproduce the 
failure.




I built using the traditional ./configure ; make -j8 and then run it with

./src/m4


Since you are building from source, you may also want to try modifying 
main() to not install a signal handler for SIGABRT; that way, the 
desired abort message will get printed rather than m4's normal attempt 
to sanitize a fatal error into a more friendly message.




This is the result of gcc --version:

Configured with: --prefix=/Library/Developer/CommandLineTools/usr 
--with-gxx-include-dir=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/c++/4.2.1
Apple clang version 11.0.0 (clang-1100.0.33.12)
Target: x86_64-apple-darwin19.0.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin

Thanks!
Vanessa McHale



--
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3226
Virtualization:  qemu.org | libvirt.org

Re: FW: divert(-1) does not work in argument

[Eric Blake]

[re-adding the list with permission]

On 11/18/19 3:17 PM, Ice Ninja wrote:

Hi Eric,



So the key thing here, looks to me, is the stream and the action of
collecting arguments phase is ignoring the stream where the text actually
is wrapped in.


The output stream is ONLY relevant to outer-most macro expansion.  All 
nested macro expansion during argument collection affect only what 
argument is collected, not what is output.




I could work around the 'unexpected' or 'unituitive' behavior with
'ignore' definition like this,
enswan@ws/m4$ m4
<<<'changequote()changequote([,])define(ignore)include(ignore(good)show)'
m4:stdin:1: cannot open `show': No such file or directory


Yes, an ignore macro is one way to ignore arbitrary text regardless of 
whether it is expanded as an outermost macro or as a nested expansion 
during argument collection.




Shouldn't the argument expansion phase also respects the end result of the
expansion including respect the stream?


During argument collection, there is no output stream, only the argument 
being collected.  There are no diversions in play except during 
outermost macros.



If not, when the argument itself is
an independent m4 script, the logic of 'running' that script will be
undergone a different mechanism which hence requires extra attention and
effort to deal with.


Parsing an m4 script in argument collection context is indeed different 
than parsing the same script in top-level context.  But that's an 
inherent design limitation of the m4 language, so not something we can 
really change.




I had no problem regards to the 1st m4 call in the last email,

enswan@ws/bin$ m4

<<<'changequote()changequote([,])divert(-1)good[]divert[]show'

show

I had it there was to show the inconsistency between the calls of m4 with
the same piece of code .

Do you have a bit feeling that my suggestion is reasonable or I should
correct myself entirely to 'think' in the way it is?


As I don't see m4 code changing, then it does seem like you'll have to 
adjust your thinking on how argument collection works.


--
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3226
Virtualization:  qemu.org | libvirt.org

Re: divert(-1) does not work in argument

[Eric Blake]

On 11/18/19 2:13 PM, Enshan Wang wrote:

enswan@ws/bin$ m4 <<<'changequote()changequote([,])divert(-1)good[]divert[]show'
show
enswan@ws/bin$ m4 
<<<'changequote()changequote([,])include(divert(-1)good[]divert[]show)'
m4:stdin:1: cannot open `goodshow': No such file or directory

Maybe it's not a bug, but I think the 2nd m4 call should show that `show': No 
such file or directory.
Looks include call still see the `good' which I want to divert to -1 i.e. it 
should be discarded.


Not a bug in m4, but in your expectations.  Let's follow exactly what 
happens as m4 expands things:


First version:
m4 <<<'changequote()changequote([,])divert(-1)good[]divert[]show'

m4 parses 'changequote(' and sees that it has to collect arguments; it 
then parses ')' and calls changequote with a single empty argument '' 
which expands to the empty string to the current output stream 0 (plus 
the side effect of resetting quote chars).  Next, m4 parses 
'changequote(', sees that it has to collect arguments, and collects the 
two arguments '[' and ']' before the closing ')', which again expands to 
the empty string '' to the current output stream 0 (as well as a side 
effect of new quote chars).  Next, m4 parses 'divert(', collects the 
single argument '-1', and expands the macro upon seeing ')'; this 
expands to the empty string but had the side effect of setting the 
current stream to -1 for discarding all expanded output.  Next m4 parses 
'good', sees that it is not a macro, and outputs it as-is (but output to 
stream -1 does nothing), parses '[]' as a string and outputs it with the 
quotes removed (but the empty string has nothing to output), then parses 
'divert' and sees that it is a macro, and invokes it with 0 arguments. 
This expands to empty text, but has the side effect of restoring the 
output stream back to 0.  Next m4 parses '[]' as another string that 
results in no output, then the text 'show' which is not a macro name and 
is output as-is.


Your other example:
m4 <<<'changequote()changequote([,])include(divert(-1)good[]divert[]show)'

starts the same for the two changequote macros.  Then m4 parses 
'include(' and sees that it has to perform argument collection. During 
that argument collection, it parses 'divert(' and sees that it has to 
start a nested macro invocation.  It then parses '-1' as the argument 
and ')' to expand the divert macro, which changes the output stream to 
-1; but we are still collecting arguments to 'include' rather than 
generating output to the output stream; so far, we collected an empty 
string '' from the expansion of divert.  Next, m4 parses 'good', sees 
that it is not a macro name, and appends it to the argument being 
collected.  Similarly for parsing '[]' which gets quotes stripped and 
appends '' to the argument being collected.  Then 'divert' which is a 
macro call with 0 arguments, restoring the output stream to 0 with NO 
output having been produced to any output stream in the meantime, 
appending another '' to the argument collection.  Then '[]' which 
appends another '', and finally 'show' which is appended as is.  Putting 
it all together, when m4 finally sees ')', it has collected a single 
argument 'goodshow', which m4 correctly tells you is not the name of an 
existing file to be included.





My version is 1.4.18. I did not try 1.6 version of m4. (BTW what's the status 
of m4 1.6? should I use m4 1.6 or 1.4...?)


m4 1.4.x is the latest stable version.  I need to post a refresh version 
(there have been FTBFS reports where the existing m4 release is 
incompatible with newer glibc headers), but that's not difficult. 
Getting 1.6 complete will require more time on my part, which I have not 
seemed to have lately.



CONFIDENTIALITY AND PRIVACY NOTICE: This e-mail and any attachments are for the 
exclusive and confidential


Claims like this are unenforceable on publicly-archived mailing lists. 
You may wish to send future emails from other than your employer's 
servers that slams this garbage legalese on your outgoing mails.


--
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3226
Virtualization:  qemu.org | libvirt.org

Re: Test failure in GNU M4 1.4.18 with musl libc

[Eric Blake]

On 9/11/19 2:58 PM, Cody Logan wrote:
> Hello,
> 
> I'm attempting to cross-compile M4 1.4.18 with musl libc instead of
> glibc. The build completes, but when I run `make check`, I get two test
> failures. I'm running Arch Linux x86-64 on Linux 5.2.13 and
> cross-compiling with GCC 9.2.0 (targeting x86_64-pc-linux-musl).FWIW,
> the same failures occur on Alpine Linux with native GCC 8.3.0.

Both of these failed tests come from gnulib (added in cc); I'm not sure
if they have been fixed in the meantime (in which case, you just need to
wait for an eventual m4 1.4.19 that uses a newer gnulib) or represent
problems that others will still hit.


> FAIL: test-localename
> =
> 
> test-localename.c:183: assertion 'strcmp (name, "fr_FR.UTF-8") == 0' failed
> FAIL test-localename (exit status: 134)
> 

> 
> FAIL: test-mbrtowc5.sh
> ==
> 
> test-mbrtowc.c:106: assertion 'wc == c' failed
> ./test-mbrtowc5.sh: line 4: 789048 Aborted (core dumped)
> LC_ALL=C ./test-mbrtowc${EXEEXT} 5
> FAIL test-mbrtowc5.sh (exit status: 134)
> 
But on the bright side, it probably does not represent an actual bug in
your just-built m4.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3226
Virtualization:  qemu.org | libvirt.org

Re: Potential bug with my --synclines

[Eric Blake]

On 6/6/19 2:47 PM, Laura Wills wrote:
> Hi,
> 
> I am running into an issue with m4 synclines. I have a list of m4 files which 
> point to child m4 files. This reaches a hierarchy level of 12. When I write 
> out a list of these m4 files and one at a time read them with m4 synclines I 
> am able to read them without an issue. When I put this into a recursive loop 
> at some point m4 synclines stops returning any value. The return code does 
> show that an error is occurring, but I cannot determine what the issue is. I 
> have tried the different -debug options, and have had no luck.
> 
> In the recursive function I am getting a list of all included m4 files at the 
> current level, writing them to a file, and then closing that file. Once the 
> file is closed, I recursively call the function on the new list of m4 files.  
> I am using perl `m4 -synclines $infile > $output`.

Can you post actual contents of (a reduced) $infile that reproduce the
problem? The issue doesn't sound familiar, but I cannot decipher your
prose into a reproducible case nearly as fast as I could inspect your
input files to see if there was an obvious problem either in your input
files or in m4 itself.

> 
> The version of m4 I am using is 1.4.13. I am running on RHEL6.
> 
> Is this a known issue?
> 
> Thanks,
> Laura
> 
> 

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3226
Virtualization:  qemu.org | libvirt.org



signature.asc
Description: OpenPGP digital signature

Re: vague question

[Eric Blake]

On 3/19/19 8:18 PM, Mahendra Yadav wrote:
> my gionee m4 can not downloaded latest version

I'm not exactly sure what you are asking. Are you having problems
finding the m4 download site? Or once it is downloaded, are you having
problems compiling? More details about the actual commands you typed and
error messages you are getting would be useful, as well as details about
your platform. Does your vendor ship a pre-compiled version of m4
instead of you having to download the sources to build yourself?

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3226
Virtualization:  qemu.org | libvirt.org



signature.asc
Description: OpenPGP digital signature

Re: document bugs

[Eric Blake]

[I'm not sure why the original mail didn't seem to hit the list]

On 2/26/19 1:34 PM, HaimMelamed wrote:
> hello,
> after reading, maybe its better to change words like "while" with "wereas"
> or "despite of" or "in contrast of" ..
> because the confusion of known operational commands like "ifelse" or
> "forloop" or "while" or "until".
> best regards
> 

Rather than a vague suggestion, it's easier to evaluate this if you can
propose an actual patch (showing both the before and after of a sentence
you find confusing without your rewording).

"despite of" and "in contrast of" are not idiomatic English; while I
don't mind helping you come up with grammar that matches a native
speaker's expectations, it's hard to do that without having an actual
sentence being changed, rather than just a couple of words from an
unspecified sentence.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3226
Virtualization:  qemu.org | libvirt.org

Re: Encounter problems when installing m4

[Eric Blake]

On 1/31/19 2:10 AM, 張倚馨 wrote:
> Hi GNU,
> 
> Please take a look at my question posted on stackoverflow and I will be
> appreciated if you can help me fix this. Thanks!
> Link:
> https://stackoverflow.com/questions/54454753/gnu-m4-install-failed-after-make-command

Even better than making readers chase a link is to just post your actual
question here:

> 
> Here are the steps I took on cygwin:
> 
>  - wget http://mirrors.kernel.org/gnu/m4/m4-1.4.18.tar.gz
>  - tar -xzvf m4-1.4.18.tar.gz
>  - cd m4-1.4.18
>  - ./configure --prefix=/usr/local/
>  - make
> 
> The terminal(cygwin) shows these:
> 
> C:/Program Files (x86)/GnuWin32/bin/make all-recursive process_begin: 
> CreateProcess(NULL, /usr/bin/sed -n

Umm - that says you are using GnuWin32's make, not Cygwin's make.
Mismatching your build environment (by mixing two incompatible ports) is
a recipe for disaster.

If you are using Cygwin, then why not use Cygwin's pre-built m4 package
instead of trying to build it yourself? But if you are going to build
it, at least use Cygwin's make.  You'll probably need to fix your $PATH
to be something sane.

At any rate, your problem has nothing to do with upstream m4, and
everything to do with your environment, so this list is not going to be
the best source of help, compared to the Cygwin or GnuWin32 communities.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3226
Virtualization:  qemu.org | libvirt.org



signature.asc
Description: OpenPGP digital signature

Re: m4 failure on OS X High Sierra, with patch

[Eric Blake]

On 06/23/2018 01:48 PM, George Hartzell wrote:


Hi All,

I'm ensuring that the Spack packager can build m4 on OS X High Sierra.

Here's my PR for them:

 https://github.com/spack/spack/pull/8559


Making someone chase a URL is not friendly for long-term archives. 
Here's a summary:


+With format string strictness, High Sierra also enforces that %n isn't used
+in dynamic format strings, but we should just disable its use on darwin in
+general.
+
+--- a/lib/vasnprintf.c.orig2017-06-22 15:19:15.0 -0700
 b/lib/vasnprintf.c 2017-06-22 15:20:20.0 -0700
+@@ -4869,7 +4869,7 @@ VASNPRINTF (DCHAR_T *resultbuf, size_t *
+ #endif
+   *fbp = dp->conversion;
+ #if USE_SNPRINTF
+-# if !(((__GLIBC__ > 2 || (__GLIBC__ == 2 && __GLIBC_MINOR__ >= 3)) && 
!defined __UCLIBC__) || ((defined _WIN32 || defined __WIN32__) && ! 
defined __CYGWIN__))
++# if !defined(__APPLE__) && !(((__GLIBC__ > 2 || (__GLIBC__ == 2 && 
__GLIBC_MINOR__ >= 3)) && !defined __UCLIBC__) || ((defined _WIN32 || 
defined __WIN32__) && ! defined __CYGWIN__))

+ fbp[1] = '%';
+ fbp[2] = 'n';
+ fbp[3] = '\0';

In other words, you are patching gnulib to work around MacOS's new 
strictness that prevents the POSIX-compliant use of %n within 
snprintf().  As similar patches have already been made in upstream 
gnulib, the next release of m4 should automatically work with newer 
MacOS by virtue of updating to a newer gnulib.


--
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3266
Virtualization:  qemu.org | libvirt.org

Re: Problem with --version after compiling autoconf

[Eric Blake]

On 05/30/2018 07:23 AM, Eric Blake wrote:

which in turn is expanding this macro before calling m4's eval with 
invalid input:


m4_bpatsubst(m4_bpatsubst(m4_translit(0,$1, [.-], [,,]),]dnl
m4_dquote(m4_dquote(m4_defn([m4_cr_Letters])))[[+],
   [+1,-1,[0r36:\&]]), [,0], [,[0r10:0]])


In fact, this used to work for single (but not multiple) letters; commit 
6e1d6e2c (added in 2.63, Oct 2007) changed from a manual comparison of 
the three contiguous regions of a-z in EBCDIC into using m4's 0r36:NNN 
notation:


-[m4_translit(m4_bpatsubsts(m4_tolower([[$1]]),
-  [\([0-9]+\)\([abcdefghi]\)],
-[m4_eval(\1 + 1).-1.\2],
-  [\([0-9]+\)\([jklmnopqrs]\)],
-[m4_eval(\1 + 1).-1.1\2],
-  [\([0-9]+\)\([tuvwxyz]\)],
-[m4_eval(\1 + 1).-1.2\2]),
-[abcdefghijklmnopqrstuvwxyz],
-[12345678901234567890123456])])
+[m4_map_sep([m4_eval], [.], _$0([$1]))])
+m4_define([_m4_version_unletter],
+[m4_translit(m4_bpatsubst([[[$1]]], ]dnl
+m4_dquote(m4_dquote(m4_defn([m4_cr_Letters])))[[+],
+   [+1.-1.[0r36:\&]]),

So you've found a 10-year-old bug in autoconf, and an even older bug in 
m4.  As least as far back as m4 commit bd11691d (Feb 2000, marked 
"Initial revision", which is when the current m4.git history starts), 
and the m4 1.4 release, m4's eval(0r36:NN) notation has been broken; 
more likely, all the way back to Nov 1993 when Francois Pinard 
introduced 0rNNN syntax into m4 1.1 (according to NEWS), although I 
cannot locate a tarball or version control of m4 that old.


It's worth patching m4 to not botch large-radix numbers on EBCDIC, but 
it's also possible to patch autoconf to quit relying on large-radix 
numbers; I'll probably end up patching both projects, when I get a chance.


--
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3266
Virtualization:  qemu.org | libvirt.org

Re: Problem with --version after compiling autoconf

[Eric Blake]

On 05/30/2018 03:24 AM, Andy Armstrong wrote:

Hi Eric,


I ran 'make check' and got the following :




autom4te_perllibdir='..'/lib AUTOM4TE_CFG='../lib/autom4te.cfg' 
../bin/autom4te -B '..'/lib -B '..'/lib --language=autotest -I . -I . suite.at 
-o ./testsuite.tmp


The command looks reasonable,


m4:local.at:18: bad expression in eval (bad input): ((?+1+0) > (2+0)) - ((?+1+0) 
< (2+0))
autom4te: /workarea/tools/m4/bin/m4 failed with exit status: 1


but things are choking hard at:

m4_version_prereq([2.57])

which expands:

[m4_if(m4_version_compare(]m4_dquote(m4_defn([m4_PACKAGE_VERSION]))[, [$1]),
[-1],
[m4_default([$3],
[m4_fatal([Autoconf version $1 or higher is required],
  [63])])],
[$2])]


which in turn is expanding this macro before calling m4's eval with 
invalid input:


m4_bpatsubst(m4_bpatsubst(m4_translit(0,$1, [.-], [,,]),]dnl
m4_dquote(m4_dquote(m4_defn([m4_cr_Letters])))[[+],
  [+1,-1,[0r36:\&]]), [,0], [,[0r10:0]])

What are the contents of lib/m4sugar/version.m4?  But I suspect that 
part is fine.


Actually, I'm now quite certain that the m4_bpatsubst is not properly 
transliterating EBCDIC values into a base-36 number.  And in fact, 
looking at m4's source code, the problem is in m4 itself:


m4/src/eval.c:eval_lex()


  /* FIXME - this calculation can overflow.  Consider xstrtol.  */
  *val = 0;
  for (; *eval_text; eval_text++)
{
  if (isdigit (to_uchar (*eval_text)))
digit = *eval_text - '0';
  else if (islower (to_uchar (*eval_text)))
digit = *eval_text - 'a' + 10;
  else if (isupper (to_uchar (*eval_text)))
digit = *eval_text - 'A' + 10;

which means that anything larger than radix 20 (0-9 and a-j) is botched 
on an EBCDIC machine.


--
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3266
Virtualization:  qemu.org | libvirt.org

Re: Segmentation fault when compiling m4 1.4.18

[Eric Blake]

[re-adding the lists with permission]

On 05/23/2018 05:47 PM, Eve Armstrong wrote:

Hi Eric -


Is it okay if I post your question on public lists?

Yes, absolutely.


If you are using Cygwin, why not just use Cygwin's pre-built m4, instead

of rebuilding it yourself?
So sorry, I am ignorant: cygwin has a pre-built m4?


Yes. 
https://cygwin.com/cgi-bin2/package-cat.cgi?file=x86_64%2Fm4%2Fm4-1.4.18-1=m4.exe



 I am doubting that
this is the case, because I need m4 in order to install GNU's autoconf,
which requires m4.  And the autoconf installation fails to detect m4.


Cygwin also has pre-built autoconf. 
https://cygwin.com/cgi-bin2/package-grep.cgi?grep=autoconf=x86_64





Also, cygwin now ships with a newer gcc, so even if gcc 4.9.3 segfaults,

it may be that upgrading your

cygwin installation will get a compiler that no longer has the bug.

I may try that.  Thank you.


gcc 4.9.3 is ancient; cygwin currently ships with gcc 7.3.0: 
https://cygwin.com/cgi-bin2/package-grep.cgi?grep=gcc.exe=x86_64


but if your compiler bug still persists, then emailing cyg...@cygwin.com 
is the place to report your compilation problems.




Would compiling manually - i.e. executing gcc commands on the command line

- be likely to help?  If so, might you point me to




No. Make is invoking gcc commands on the command line on your behalf; but

if gcc has a bug, then that

bug will trigger whether you type the command or whether make types the

command on your behalf.
I see.  Okay.  Thank you.



--
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3266
Virtualization:  qemu.org | libvirt.org

Re: Segmentation fault when compiling m4 1.4.18

[Eric Blake]

On 05/23/2018 03:41 PM, Eve Armstrong wrote:

Hi -

I encounter a segmentation fault when compiling M4.

Platform: Windows 10.0.16299 Build 16299.

Compiler: 'make'.


No, 'make' is not your compiler.



Version of M4: 1.4.18.



   CC   strtod.o
strtod.c: In function 'scale_radix_exp':
strtod.c:90:19: internal compiler error: Segmentation fault
if (r < -DBL_MAX / radix)
^
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
Makefile:1910: recipe for target 'strtod.o' failed


This is a bug in gcc on your platform, although since the source file 
was provided by gnulib, it might be nice if gnulib were able to avoid 
tickling the gcc bug (if we can even figure out what it is about the 
file that gcc choked on).  Have you opened a gcc bug as requested by the 
compilation failure message?  If so, which bug is it?


Also, did you build gcc yourself, or are you using a pre-built gcc?  Who 
provided the pre-built gcc, Microsoft?  Have you filed a bug report with 
them to let them know about their build of the compiler having a bug?


--
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3266
Virtualization:  qemu.org | libvirt.org

Re: M4 examples not installed

[Eric Blake]

On 03/18/2018 08:50 AM, Werner LEMBERG wrote:


[Please CC to me since I'm not on the list.]


Is there a specific reason why the M4 examples are not installed?


Because no one has ever asked for them to be installed.


 I
suggest to add them.


Is installing the manual not sufficient for finding the examples?  Where 
would you suggest that the examples be installed?  Are you willing to 
prepare a patch?


--
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3266
Virtualization:  qemu.org | libvirt.org

Re: m4: internal error detected

[Eric Blake]

On 03/17/2018 03:45 PM, Shanmugasundaram Aruchamy wrote:

Hi,
While building from the yocto project on Windows Subsystem for Linux ( Ubuntu
)
got the following failure,




/home/sundar/yocto/poky/build/tmp/work/x86_64-linux/libtool-native/2.4.6-r0/libtool-2.4.6/m4/
-I
/home/sundar/yocto/poky/build/tmp/work/x86_64-linux/libtool-native/2.4.6-r0/libtool-2.4.6/tests/
--force -I m4
| m4: ../sysdeps/unix/sysv/linux/spawni.c:368: __spawnix: Assertion `ec >=
0' failed.
| m4: internal error detected; please report this bug to <bug-m4@gnu.org>:


Wow.  That's a failure in your system runtime, and not in m4 proper. 
There's nothing we can do on the m4 list to debug your broken system.  I 
suspect that the bug lies in the Windows Subsystem for Linux, and that 
you'll have to report it there.



Aborted
| autom4te: m4 failed with exit status: 2
| aclocal: error: echo failed with exit status: 2
| autoreconf: aclocal failed with exit status: 2
| ERROR: autoreconf execution failed.

Thank you,
Regards
SUNDAR



--
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3266
Virtualization:  qemu.org | libvirt.org

Re: https://www.gnu.org/software/m4/manual/m4.html - UPDATE

[Eric Blake]

On 02/11/2018 12:20 PM, Howard Johnson wrote:
OOPs.  Now I see that in fact the leading quote is a back tick (not a 
single tick), while the trailing quote is a single tick.  Strange.


Might be good to spell this uncommon usage out more clearly in 
https://www.gnu.org/software/m4/manual/m4.html#Quoted-strings


i.e. say:

     A quoted string is a sequence of characters surrounded by quote 
strings, defaulting to ‘`’ (back tick) and ‘'’ (single quote), where the 
nested begin and end quotes within the string are balanced. The value of 
a string token is the text, with one level of quotes stripped off.


rather than just:

     A quoted string is a sequence of characters surrounded by quote 
strings, defaulting to ‘`’ and ‘'’, where the nested begin and end 
quotes within the string are balanced. The value of a string token is 
the text, with one level of quotes stripped off.


Sure, we can apply that patch (patches are easier to read in diff 
format, but it looks like all you did was add the strings "(back tick)" 
and "(single quote)" in the right places).


--
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3266
Virtualization:  qemu.org | libvirt.org

Re: https://www.gnu.org/software/m4/manual/m4.html

[Eric Blake]

On 02/11/2018 12:09 PM, Howard Johnson wrote:

Hi,

In the m4 documentation web page, for example at 
https://www.gnu.org/software/m4/manual/m4.html#Comments 
<mailto:bug-m4@gnu.org>, the character used for an opening single quote 
displays incorrectly.  Here is a snapshot:







Your snapshot did not render correctly in plain text.




I'm pretty sure what is meant is that the same character is used both 
before and after *quoted text* above. 


No, that is NOT what is meant.

But what appears is a slanted 
tick and then a straight tick.


Yes, that is correct.



I think this should read:

    $m4

    'quoted text' # 'commented text'


Wrong.

The default m4 quoting strings are back-tick (`, ASCII 96) for opening 
quote, and single-quote (', ASCII 39) for closing quote.  Yes, they are 
asymmetrical, and that is intentional.



    ...


If I disable the style sheet I still see them wrong, so it's not a css 
thing:




Also this is not dependent on browser, i.e. Firefox and Chrome both 
display this the same.


Good - because that's what they are supposed to display.

--
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3266
Virtualization:  qemu.org | libvirt.org

Re: /usr/bin/m4: internal error detected

[Eric Blake]

On 11/30/2017 11:08 PM, Daniel Kahn Gillmor wrote:

Hi m4 and sh4 folks--

Debian's GnuPG package (version 2.2.3-1) is failing to build on the sh4
architecture, as seen here:

https://buildd.debian.org/status/fetch.php?pkg=gnupg2=sh4=2.2.3-1=1512098830=0

the error log looks like:


Copying file po/Makefile.in.in
Copying file po/Makevars.template
qemu: Unsupported syscall: -1
m4: ../sysdeps/unix/sysv/linux/spawni.c:366: __spawnix: Assertion `ec >= 0' 
failed.
/usr/bin/m4: internal error detected; please report this bug to 
<bug-m4@gnu.org>: Aborted
---

So, i'm reporting it here.

Not sure what to make of it, or how to try to resolve it.


It sounds like you aren't on a bare-metal sh4 machine, but rather that 
you are on a VM, and that your VM has tripped up on a qemu emulation 
bug.  As such, the fix to your problem is to get the qemu folks to 
figure out why sh4 isn't being emulated correctly, and is not really 
something that m4 is at fault for (other than m4 managed to trigger the 
non-emulated syscall).


--
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3266
Virtualization:  qemu.org | libvirt.org

Re: GNU-M4 Installation Error

[Eric Blake]

On 11/01/2017 04:26 AM, Sai Siva wrote:
> Hi,
> 
> I have tried to install *GNU m4* *(Version m4-1.4.18)* which is required
> for *ParallelNetCDF* software installation. However, the installation of
> this package does not work on my computer as it is giving some error
> messages.
> 
> I have used the following commands:
> 
> 
> *./configure*
> 
> *make*
> *make install*
> 
> The first two commands seems to be working. But, I am struggling with the
> last command "make install".
> 
> The screenshot *(After_MakeInstall.png) *attached with this mail shows *"make
> install"* error.

No screenshot was attached.  (And even then, attaching screenshots
instead of copy-and-pasting the text contained within the window tends
to be a waste of bandwidth).

But I will assume that the error message had something to do with
incorrect permissions to install things?  If you run ./configure without
any other options, the default is that the package will set itself up to
install in /usr/local - but that is a directory with system-wide
consequences, and so you usually have to run 'sudo make install' or some
other similar way to install the software for all users of the machine.
It is also possible to run './configure --prefix=$HOME' to let the
installation know that you'd rather stick things in your home directory
rather than system-wide, and that tends to not need root permissions.

> 
> Kindly suggest me how to resolve this error.
> 
> 
> I am using Ubuntu-16.04 OS.

It may also be worth contacting your vendor for help; since you are
using pre-built software for the bulk of your machine, running a
pre-built M4 may be easier than struggling with re-building it yourself.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3266
Virtualization:  qemu.org | libvirt.org



signature.asc
Description: OpenPGP digital signature

Re: some questions about M4RI source

[Eric Blake]

On 10/24/2017 02:57 PM, 明天 wrote:
> Dear Martin R. Albrecht:

...
>I learn a lot in the web of M4RI ,thanks to your code sources.I want 
> to solve the linear equations by using the m4ri algorithm.

You probably did not mean to include bug-m4 AT gnu.org mailing list in
your to: list, as GNU m4 is a completely different project
(https://www.gnu.org/software/m4/) than m4ri
(https://bitbucket.org/malb/m4ri).

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3266
Virtualization:  qemu.org | libvirt.org



signature.asc
Description: OpenPGP digital signature

Re: POSSIBLE_DOC_BUG

[Eric Blake]

On 08/25/2017 10:14 AM, 宋增强 wrote:
> I did what the document says and I found the directive "define" didn't work
> for me.
> 
> You see.The doc says I should use doc like " define('twoline','12')

No, the documentation states you should use:

define(`twoline', `12')

(note that the use of `' quoting is very important; using '' is not
properly quoting things)

> ".However,I found I need to use it like " define(twoline,12) "

That "works" for one use only, but fails if you do it two times in a
row.  The first argument of define MUST be quoted, to prevent a second
definition from failing because it is now defining what the macro name
expanded to, rather than re-defining the desired macro.  That point is
also covered in the manual.

> 
> I am not really good at english and unix things.So if anything is
> wrong,please forgive me.^-^!

At this point, I don't see any documentation bug, but rather just a
confusion on your part about what the proper default quoting characters are.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3266
Virtualization:  qemu.org | libvirt.org



signature.asc
Description: OpenPGP digital signature

Re: Problem compiling GNU M4

[Eric Blake]

[adding gnulib]

On 07/14/2017 04:32 AM, Reinier Glez wrote:
> Good morning,
> 
> I'm trying to compile a GNU M4 version 1.4.18 with XLC compiler and I have
> the following error:
> 
> 
> make  all-recursive
> Making all in .
> Target "all-am" is up to date.
> Making all in examples
> Target "all" is up to date.
> Making all in lib
> make  all-am
>   CC   c-ctype.o
> "c-ctype.h", line 174.5: 1506-052 (S) Duplicate case label for value 48.
> Labels must be unique.
> "c-ctype.h", line 175.5: 1506-076 (W) Character constant '\'A\' - \'a\''
> has more than one character. No more than rightmost 4 characters are used.

c-ctype.h comes from gnulib, so presumably that's the place that needs
to be fixed, and you will probably see similar compilation failures on
other projects until we figure out why your compiler is griping about
the file.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3266
Virtualization:  qemu.org | libvirt.org



signature.asc
Description: OpenPGP digital signature

Re: Problem: ifelse ifelse define conbination

[Eric Blake]

`ARG6',ARG3)dnl

And likewise.

> define(`VERSION',`1.0.0')TestIfelseDefine.m4 VERSION: Before arg1=ARG1 
> arg2=ARG2 arg3=ARG3 arg4=ARG4 arg5=ARG5 arg6=ARG6 store_arg3=STORE_ARG3
> ifelse(ARG1,`OPT11',,`define(`STORE_ARG3',ARG3)')dnl

So this says: if the expansion of ARG1 matches the string OPT11, do
nothing, otherwise expand "define(`STORE_ARG3', ARG3)", which would
result in defining the macro STORE_ARG3 to contain the expansion of the
ARG3 macro (that is, the text OPT3 given your command line).  It may be
underquoted, but I don't yet know how you plan to use this.

> ifelse(ARG2,`OPT21',`define(`ARG3',OPT39)',`define(`ARG3',OPT38)')dnl

This says: if the expansion of ARG2 matches the string OPT21, then
expand "define(`ARG3', OPT39)" (there is no macro named OPT39, so
redefine the ARG3 macro to the text OPT39); if the text does not match,
then expand "define(`ARG3', OPT38)" (there is no macro named OPT38, so
redefine the ARG3 macro to the text OPT38).  Again, it is probably
underquoted if you ever plan on defining a macro named OPT38 or OPT39.

> ifelse(ARG1,`OPT11',,`define(`ARG3',STORE_ARG3)' `undefine(`STORE_ARG3')')dnl

This says: if the expansion of ARG1 matches the string OPT11, do
nothing, otherwise expand "define(`ARG3',STORE_ARG3)
undefine(`STORE_ARG3')", which in turn results in re-defining the ARG3
macro to the expansion of the STORE_ARG3 macro, then undefining the
STORE_ARG3 macro.

> ifelse(ARG1,`OPT12',`define(`ARG4',OPT49)',`define(`ARG5',OPT59)')dnl

Similar analysis.

> ifelse(ARG1,`OPT11',ifelse(ARG2,`OPT21',`define(`ARG6',OPT69)',`define(`ARG6',OPT68)'))dnl

Ah, here we get to your bug.  Remember, m4 ALWAYS looks for macro
expansions while collecting macro arguments.  But you did not quote the
inner ifelse macro.  Therefore, the inner ifelse is expanded first.

Execution-wise, you have told m4 to expand
"ifelse(ARG2,`OPT21',`define(`ARG6',OPT69)',`define(`ARG6',OPT68)')"
first, and use the result of that expansion as the 3rd argument to the
outer ifelse.

But what is the expansion of that inner ifelse?  If the expansion of
ARG2 matches the string OPT21, then it is the expansion of
"define(`ARG6',OPT69)"; if it does not match, then it is the expansion
of "define(`ARG6',OPT68)".  Either way, you are expanding the define
macro to define ARG6 (either to the value OPT69 or OPT68), and the
expansion of define is the empty string.

So you are in effect causing side-effects to happen (ARG6 was defined no
matter what) prior to executing the outer ifelse, which now looks like:
"ifelse(ARG1,`OPT11',)"
which is a no-op.

You probably WANTED to do this (where I'm intentionally using m4's
ability to ignore whitespace after comma to make things more legible):

ifelse(ARG1, `OPT11',
   `ifelse(ARG2, `OPT21',
   `define(`ARG6', OPT69)',
   `define(`ARG6', OPT68)')')dnl

Note the additional level of `' added around the inner ifelse.  Now, the
collection of arguments of the outer ifelse sees only a string, which
means that if the expansion of ARG1 matches the string OPT21, then
expand the inner string, so the inner ifelse happens only if the outer
ifelse was satisfied, rather than unconditionally.

-- 
Eric Blake   eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature

Re: compiler error on macOS Siera with GCC@6.2.1

[Eric Blake]

On 09/23/2016 01:19 PM, Denis Davydov wrote:
> Hi Eric,
> 
> Thanks for the swift reply.
> 

>>
>> Can you look in config.log, and see why configure seems to think that
>> HAVE_STRUCT_SCHED_PARAM was set to 0 on your platform (since it is
> 
> it is indeed set to 0. Searching for HAVE_STRUCT_SCHED_PARAM in config.log
> reveals a single line only, so i don’t know where it is set and why.
> Config log is attached.

Thanks.  The log includes:

configure:28741: /Users/davydden/spack/lib/spack/env/gcc/gcc -c -g -O2
-I/Users/davydden/spack/opt/spack/darwin-sierra-x86_64/gcc-6.2.0/libsigsegv-2.10-dduf3ib2khihptbot54hgma7ow2f3zcx/include
conftest.c >&5
In file included from /usr/include/sched.h:27:0,
 from conftest.c:274:
/usr/include/pthread_impl.h:32:18: error: missing binary operator before
token "("
 #if __has_feature(assume_nonnull)
  ^
/usr/include/pthread_impl.h:62:18: error: missing binary operator before
token "("
 #if __has_feature(assume_nonnull)
  ^
conftest.c:277:8: error: unknown type name 'pid_t'
pid_t t1;
^
configure:28741: $? = 1
configure: failed program was:
...

| /* end confdefs.h.  */
|
|#include 
|struct sched_param a;
|int b[] = { SCHED_FIFO, SCHED_RR, SCHED_OTHER };
|pid_t t1;
|
| int
| main ()
| {
|
|   ;
|   return 0;
| }
configure:28828: checking for struct sched_param
configure:28828: /Users/davydden/spack/lib/spack/env/gcc/gcc -c -g -O2
-I/Users/davydden/spack/opt/spack/darwin-sierra-x86_64/gcc-6.2.0/libsigsegv-2.10-dduf3ib2khihptbot54hgma7ow2f3zcx/include
conftest.c >&5
In file included from /usr/include/sched.h:27:0,
 from conftest.c:273:
/usr/include/pthread_impl.h:32:18: error: missing binary operator before
token "("
 #if __has_feature(assume_nonnull)
  ^
/usr/include/pthread_impl.h:62:18: error: missing binary operator before
token "("
 #if __has_feature(assume_nonnull)
  ^
configure:28828: $? = 1
configure: failed program was:
...

and it looks like the test program tried a bunch of #define followed by
an #include  as its first header.

So something about your system is causing the inclusion of  in
isolation to be treated as a syntax error when it calls out to
/usr/include/pthread_impl.h.  I don't know what is supposed to be
happening with the __has_feature() stuff, or if including some other
header prior to  will avoid the compilation error; but the
reason your compilation failed is because configure was unable to probe
for the presence of sched_param due to the unrelated compilation failure.

Is that something you can figure out where things are going wrong, or if
an additional header included before  fixes things?

>> around the issue by setting appropriate cache variables during the
>> configure run?
> 
> I tried adding
> 
> HAVE_STRUCT_SCHED_PARAM=1
> 
> to ./configure but it does not change anything. How do I do that?

./configure ac_cv_type_struct_sched_param=yes

If that works, it is basically telling configure the desired answer to
the probe (the answer that is not happening due to the unrelated syntax
error).

-- 
Eric Blake   eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature

Re: ERROR report

[Eric Blake]

On 09/19/2016 10:57 PM, Danlan Chen wrote:
> Hello,
> I have this error below when I am trying to install m4, do you have any
> suggestion?

> /bin/bash: line 4: 20410 Aborted (core dumped) EXEEXT=''
> EXEEXT='' EXEEXT='' srcdir='.' EXEEXT='' srcdir='.' EXEEXT='' srcdir='.'
> ${dir}$tst
> 
> FAIL: test-vasnprintf
> 
> *** %n in writable segment detected ***

All of the failures look like this.  Basically, your libc is
overly-picky and not POSIX compliant by default, on the grounds that it
is trying to prevent you from %n security holes.  You can safely ignore
the warnings (m4 itself doesn't use printf("%n"), only the testsuite
does), and go ahead and install m4.  Which libc are you using?  Maybe we
could convince gnulib's testsuite (which is the source of the failing
tests) to work around your libc's pickiness.

-- 
Eric Blake   eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature

Re: make check fails for m4-1.4.17

[Eric Blake]

On 07/13/2016 10:14 AM, Ambrose LI wrote:
> The development version in git appears to be identical to 1.4.17.
> 
> 
> test-update-copyright.sh.log
> 
> 
> --- - Wed Jul 13 15:57:01 2016
> +++ update-copyright.test-ex-stderr   Wed Jul 13 15:57:01 2016
> @@ -1,2 +1,18 @@
> +Unescaped left brace in regex is deprecated, passed through in regex; marked 
> by <-- HERE in m/\G(?:(?:[ \t\r\f]*(?:[ \t\r\f]|\n)[ 
> \t\r\f]*)(?:\([cC]\)|@copyright{ <-- HERE }|))?(?:[ \t\r\f]*(?:[ 
> \t\r\f]|\n)[ \t\r\f]*)(?:(?:\d\d)?\d\d(?:,(?:[ \t\r\f]*(?:[ \t\r\f]|\n)[ 
> \t\r\f]*)?|-))*((?:\d\d)?\d\d)(?:[ \t\r\f]*(?:[ \t\r\f]|\n)[ 
> \t\r\f]*)Free(?:[ \t\r\f]*(?:[ \t\r\f]|\n)[ \t\r\f]*)Software(?:[ 
> \t\r\f]*(?:[ \t\r\f]|\n)[ \t\r\f]*)Foundation,(?:[ \t\r\f]*(?:[ \t\r\f]|\n)[ 
> \t\r\f]*)Inc./ at /.tmps/source.new/m4-1.4.17/build-aux/update-copyright line 
> 174, <> chunk 1.

Thanks for the report.

This has already been fixed upstream in gnulib, and will be present in
m4 the next time m4 updates the gnulib submodule.

In the meantime, you can ignore the failure, it has no bearing on
whether the just-built m4 works.

-- 
Eric Blake   eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature

Re: M4 Failing Tests on Solaris 10 SPARC

[Eric Blake]

On 05/05/2016 01:41 PM, Mulcihy, David D wrote:
> Just doing what the message said.
> 

Thanks.  I'm adding bug-gnulib, as this test originates from there.


> 
> FAIL: test-mbrtowc3.sh
> ==
> 
> test-mbrtowc.c:119: assertion failed
> Abort - core dumped
> 
> FAIL: test-mbrtowc4.sh
> ==
> 
> test-mbrtowc.c:306: assertion failed
> 
> test-mbrtowc.c:306: assertion failed
> Abort - core dumped

I also know that there have been some recent gnulib improvements in the
handling of mbrtowc and friends; perhaps updating to the latest gnulib
has already solved the failures.

-- 
Eric Blake   eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature

Re: Fwd: Error in building and installing using make

[Eric Blake]

On 03/29/2016 11:59 PM, Shubham Naik wrote:

> hello, I tried installing m4 macro processor on ubuntu linux .
> But I am facing problem in building using make command and installing using
> make install command.
> 
> This is what I am getting:

> make[1]: Entering directory '/usr/local/m4/m4-1.4.1/examples'
> make[1]: Nothing to be done for 'all'.
> make[1]: Leaving directory '/usr/local/m4/m4-1.4.1/examples'

Umm, that's not an error message. If something went wrong, you'll need
to paste the actual error message you received, not 20 lines of text
after the error.

For that matter, are you aware that you can use 'apt' to download a
pre-built m4 for your Ubuntu Linux system, without having to worry about
building it yourself?

-- 
Eric Blake   eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature

Re: Unable to install M4 1.4.17 using PGI 15.10 compilers

[Eric Blake]

On 03/07/2016 09:45 AM, Stewart, Adam James wrote:
> Eric,
> 
> $ which automake
> /usr/bin/automake
> $ automake --version
> automake (GNU automake) 1.11.1
> Copyright (C) 2009 Free Software Foundation, Inc.
> License GPLv2+: GNU GPL version 2 or later 
> <http://gnu.org/licenses/gpl-2.0.html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.
> 
> I'm surprised that such a new version of Autotools is required. But I can 
> give it a shot.

[please don't top-post on technical lists]

You can probably get by with an older automake.  Automake has the nasty
habit of hard-coding its version string into the generated files; to
overcome that, you can try 'autoreconf --force' to do a clean build from
scratch rather than an incremental build, since it is only the
incremental builds that are picky about versioning.

-- 
Eric Blake   eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature

Re: Unable to install M4 1.4.17 using PGI 15.10 compilers

[Eric Blake]

On 03/07/2016 09:32 AM, Stewart, Adam James wrote:
> Thanks everybody,
> 
> I applied the patch to m4/extern-inline.m4 successfully, but now I am getting 
> the following error message during make:
> 
> CDPATH="${ZSH_VERSION+.}:" && cd . && /bin/sh 
> /tmp/ajstewart/spack-stage/spack-stage-wHnXsx/m4-1.4.17/build-aux/missing 
> aclocal-1.14 -I m4
> /tmp/ajstewart/spack-stage/spack-stage-wHnXsx/m4-1.4.17/build-aux/missing: 
> line 81: aclocal-1.14: command not found
> WARNING: 'aclocal-1.14' is missing on your system.
>  You should only need it if you modified 'acinclude.m4' or
>  'configure.ac' or m4 files included by 'configure.ac'.
>  The 'aclocal' program is part of the GNU Automake package:
>  <http://www.gnu.org/software/automake>
>  It also requires GNU Autoconf, GNU m4 and Perl in order to run:
>  <http://www.gnu.org/software/autoconf>
>  <http://www.gnu.org/software/m4/>
>  <http://www.perl.org/>
> make: *** [aclocal.m4] Error 127
> 
> Any idea what went wrong?

The error is pretty clear - you don't have the autotools installed (in
particular, automake 1.14), but you touched a file that requires the
autotools to propagate your change back into generated files.

It may be easier to create a new M4 tarball on a machine that has all
the usual GNU tools, then try to build that tarball with your PGI
compiler, than to try and bootstrap your PGI machine up to the point
where it can run the autotools natively.

-- 
Eric Blake   eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature

Re: On NetBSD 7.0, m4 tests fail because they use nonexistent uselocale

[Eric Blake]

On 01/17/2016 05:51 AM, Janus Troelsen wrote:
> Hi Roland,
> 
> This mailing list is dead, but I am also not sure if m4 is effectively
> supported for non-GNU platforms, as I had a problem on FreeBSD and got no
> replies.

No, the list is not dead, but just very low volume. M4 is supported on
non-GNU platforms, but only insofar as there is volunteer time
submitting problem reports and patches.

> 
> Regards,
> Janus
> 
> 2016-01-16 23:54 GMT+01:00 Roland Illig <roland.il...@gmx.de>:
> 
>> Building m4 ends with this:
>>
>> test-localename.c: In function 'test_locale_name':
>> test-localename.c:74:3: warning: implicit declaration of function
>> 'uselocale' [-Wimplicit-function-declaration]
>>uselocale (LC_GLOBAL_LOCALE);
>>^
>>
>> And later an undefined reference to uselocale.

This sounds like a failure in the gnulib testsuite, and not in m4
proper.  I'm adding the gnulib list in cc in case anyone else has seen
this problem.  It might be something that has already been fixed, where
updating m4 to use a newer gnulib snapshot would pull in the fix.

>>
>> The code already contains #ifdefs for HAVE_NEWLOCALE, but that seems to
>> be different from HAVE_USELOCALE, which also exists.
>>
>> Roland
>>
>>
> 

-- 
Eric Blake   eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature

Re: incr() and decr() don't support non-decimal arguments

[Eric Blake]

On 12/10/2014 02:36 PM, Kevin Thibedeau wrote:
 I recently ran into a problem in m4 (1.4.16) when passing hex arguments to
 the incr() and decr() builtins:
 
 incr(0x4)
 
 m4:incr.m4:1: non-numeric argument to builtin `incr'
 
 I've checked the latest versions of the 1.4 and 1.6 branches and the issue
 seems to stem from this line in numeric_arg() in builtin.c:
 
   *valuep = strtol (arg, endp, 10);
 
 The radix is fixed as base-10.

Yes, and this behavior is intentional and matches historical
implementations.  You can always do:

define(`incr', `eval(($1)+1)')

to get arbitrary bases, so it is not worth breaking historical
assumptions of incr(010) resulting in 11.

 
 I don't know if this is necessarily a bug since the POSIX and GNU docs are
 vague about the acceptable arguments other than that they must be numeric
 or integers. It seems to me that all of the numeric formats supported by
 eval() should also work with incr() and decr().

POSIX is explicit:
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/m4.html
Except for the first argument to the eval macro, all numeric arguments
to built-in macros shall be interpreted as decimal values.

 
 As a partial fix, the base in strtol() could be changed to 0 to get support
 for octal and hex literals but that leaves binary and arbitrary bases
 unsupported. At a quick glance it looks like eval_lex() could be used for
 converting numeric arguments in all formats after a check for unary +/- at
 the start of a string. The fix could be restricted to m4_incr() and
 m4_decr() if there is concern about breaking legacy m4 code using other
 builtins that call numeric_arg().

Thanks for the suggestion, but taking it would violate POSIX.  About all
we can do is enhance the documentation that you found unclear, to make
it obvious that eval is the only builtin that takes non-decimals.
Suggestions on wording or locations within the docs to update?

-- 
Eric Blake   eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature

Re: recent changes to obstacks cause many out of memory failures in M4 master testsuite

[Eric Blake]

On 12/05/2014 12:03 PM, Gary V. Vaughan wrote:

 Bisecting my way to the the first gnulib changeset that causes these 
 failures, I landed at:
 
   bb2ab7e 2014-10-29 14:02 Alan Modra   obstack: 64-bit obstack support, part 
 2
 
 Which is not surprising as GNU M4 uses GNU obstack extensively throughout.

I bet it has to do with this:

src/builtin.c:  obstack_blank (data-obs, sizeof (symbol *));
src/builtin.c:  obstack_blank_fast (obs, len);
src/builtin.c:  obstack_blank (obs, -1);
src/macro.c:   obstack_blank is documented to take a negative size to
reduce the
src/macro.c:  obstack_blank (argv_stack, -argc * sizeof (token_data *));

vs. the discussion on gnulib that we intentionally changed upstream
obstack_blank to no longer do this, and that you HAVE to use
obstack_blank_fast to get that effect.

-- 
Eric Blake   eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature

Re: m4-1.4.17 test-mbrtowc3.sh fails on Solaris without European localization

[Eric Blake]

On 11/07/2014 09:08 AM, Daiki Ueno wrote:
 Eric Blake ebl...@redhat.com writes:
 
 [adding gnulib]

 On 11/06/2014 11:19 AM, Kiyoshi KANAZAWA wrote:
 Hello,

 On Solaris 10 x86/x64,
 test-mbrtowc3.sh fails if European localization is not installed.
 It passes with European localization.
 
 I can reproduce it, and it seems to be the same issue as:
 https://lists.gnu.org/archive/html/bug-gnulib/2014-10/msg0.html
 which I originally encountered on Solaris 11.
 (It's curious that you could work it around by installing European
 localization, while the test checks the mbrtowc behavior under Japanese
 locale.)
 
 Perhaps it would be good to replace mbrtowc on Solaris, though I have no
 idea how to detect the wrong behavior without depending on particular
 locale data.  Alternatively, we could simply ignore this test failure on
 Solaris, since the tested calling convention is not very common.

I think it's better to declare the function broken and work around it
than to just ignore it in the testsuite; but like you, I'm not sure how
to easily expose the brokenness during a configure test, especially if
someone is building a binary on a machine with a locale that fixes the
issue but then wants to run the binary on another machine lacking the
locale.

-- 
Eric Blake   eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature

Re: m4-1.4.17 test-mbrtowc3.sh fails on Solaris without European localization

[Eric Blake]

[adding gnulib]

On 11/06/2014 11:19 AM, Kiyoshi KANAZAWA wrote:
 Hello,
 
 On Solaris 10 x86/x64,
 test-mbrtowc3.sh fails if European localization is not installed.
 It passes with European localization.

Thanks for the report.  M4 uses this test unchanged from upstream
gnulib; so fixing it there will get it fixed for the next m4 release
that uses a newer gnulib.

-- 
Eric Blake   eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature

Re: Bug#764580: m4 eats memory for breakfast (fwd)

[Eric Blake]

On 10/09/2014 01:14 PM, Eric Blake wrote:
 On 10/09/2014 12:47 PM, Eric Blake wrote:
 
 git clone git://git.debian.org/git/collab-maint/pkg-util-linux.git 
 util-linux
 cd util-linux
 git checkout v2.20.1
 ./autogen.sh
autopoint:  /usr/bin/autopoint (GNU gettext-tools) 0.19.2
 
 Okay, I am repeating the setup on my Fedora 20 system, with autopoint
 0.18.3 and m4 1.4.16; and I can reproduce that running 'autopoint
 --force' is the step in ./autogen.sh that causes m4 to run away with
 memory.  At this point, I'm suspecting an autopoint bug.
 

 Most likely, this is not a memory leak in m4, so much as a bug in
 util-linux' configure.ac that is causing m4 to go into an infinite loop.
 
 Or something in the way autopoint is running m4.

In particular, autom4te --verbose shows this is the runaway command line:

/usr/bin/m4 --nesting-limit=1024 --gnu --include=/usr/share/autoconf
--debug=aflq --fatal-warning --debugfile=/tmp/am4tSXlU7J/traces.0t
--trace=AM_GNU_GETTEXT_VERSION --trace=_m4_warn --trace=include
--trace=m4_include --trace=m4_pattern_allow --trace=m4_pattern_forbid
--reload-state=/usr/share/autoconf/autoconf/autoconf.m4f
--undefine=__m4_version__ - configure.ac  /tmp/am4tSXlU7J/output.0t

where stdin is fed the following prepended to configure.ac:

echo '\
dnl disable macros which may abort autom4te
m4_undefine([m4_assert])
m4_undefine([m4_fatal])
m4_undefine([m4_warn])
m4_undefine([m4_errprintn])
m4_undefine([m4_exit])
m4_undefine([m4_include])
m4_undefine([m4_esyscmd])
dnl macros which needs to be traced without aclocal.m4
m4_define([AM_GNU_GETTEXT], [])
m4_define([AM_GNU_GETTEXT_VERSION], [])
'

I bet if you downgrade to gettext 0.17, that things work again (it was
gettext 0.18 that tried to switch to an m4 trace run rather than a grep
for learning about the existence of gettext macros embedded in
configure.ac).  I'm still not easily seeing the inf-loop in all of that,
though.

-- 
Eric Blake   eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature

Re: Bug#764580: m4 eats memory for breakfast (fwd)

[Eric Blake]

[adding bug-gettext; this is a flaw in gettext, not m4. Two patches
below; one for util-linux, one for gettext]

On 10/09/2014 02:14 PM, Eric Blake wrote:
 On 10/09/2014 01:36 PM, Eric Blake wrote:
 
 In particular, autom4te --verbose shows this is the runaway command line:

 /usr/bin/m4 --nesting-limit=1024 --gnu --include=/usr/share/autoconf
 --debug=aflq --fatal-warning --debugfile=/tmp/am4tSXlU7J/traces.0t
 --trace=AM_GNU_GETTEXT_VERSION --trace=_m4_warn --trace=include
 --trace=m4_include --trace=m4_pattern_allow --trace=m4_pattern_forbid
 --reload-state=/usr/share/autoconf/autoconf/autoconf.m4f
 --undefine=__m4_version__ - configure.ac  /tmp/am4tSXlU7J/output.0t
 
 and adding --debug to keep the temp files, I note that the traces.0t
 file consistently gets stuck at:
 
 m4trace:configure.ac:506: -1- m4_pattern_allow([^LIBMOUNT_VERSION$])
 m4trace:configure.ac:519: -1- m4_pattern_allow([^HAVE_LIBMOUNT_MOUNT$])
 m4trace:configure.ac:546: -1- m4_pattern_allow([^H
 
 where configure.ac has at line 546:
 
 UTIL_CHECK_LIB(util, openpty)
 
 Alas, traces.0t is buffered, so it is not a precise point of where the
 loop is happening, but somewhere shortly after there is the culprit.
 I'm still trying to see if I can coax m4 into emitting more details
 about what is looping; I may have luck attaching a gdb process at the
 point it starts consuming memory...

A bit more progress: if I inject:

m4_builtin([m4exit], [33])

into key places in configure.ac, I can easily tell if the trace reaches
that point.  So I've narrowed it down to the macro call
UTIL_CHECK_SYSCALL at line 745 of the configure.ac; the trace easily
gets through everything earlier than that point, and never seems to get
to anything after that point.  So, the bug lies somewhere in the eternal
expansion of this beast:

UTIL_CHECK_SYSCALL([ioprio_set],
  [alpha],[442],
  [i*86], [289],
  [ia64*],[1274],
  [powerpc*], [273],
  [s390*],[282],
  [sparc*],   [196],
  [sh*],  [288],
  [x86_64*],  [251])

And indeed, that calls an embedded  
_UTIL_CHECK_SYSCALL_FALLBACK(m4_shift($@))

which tries to recursively step through that list.  Sadly, it recurses
by way of m4_shiftn(2, $@), and _that_ macro calls m4_assert() as part
of its means of ensuring that the recursion is sane.  It is supposed to
shift until empty.  But gettext is rudely undefining m4_assert, which
means the recursion is infinite because the next iteration is no longer
empty, but contains an unexpanded instance of m4_assert.

This patch to util-linux's configure.ac is sufficient to work around the
gettext bug.


diff --git i/configure.ac w/configure.ac
index c216045..df746ad 100644
--- i/configure.ac
+++ w/configure.ac
@@ -736,7 +736,9 @@ m4_define([_UTIL_CHECK_SYSCALL_FALLBACK],
 [m4_ifval([$1],
   [#(
   $1) syscall=$2 ;;dnl
+  m4_pushdef([m4_assert])dnl work around gettext 0.18 bug
   _UTIL_CHECK_SYSCALL_FALLBACK(m4_shiftn(2, $@))])dnl
+  m4_popdef([m4_assert])dnl
 ])


Meanwhile, this is the patch I recommend for gettext; and since this is
a build-breaker, I recommend that gettext push a new release soon
(distros can backport the fix without waiting for the release; but the
fact that the build system is BROKEN because of a flaw in gettext is a
regression from 0.17 days).


diff --git i/gettext-tools/misc/autopoint.in
w/gettext-tools/misc/autopoint.in
index c31943f..87ee374 100644
--- i/gettext-tools/misc/autopoint.in
+++ w/gettext-tools/misc/autopoint.in
@@ -1,6 +1,6 @@
 #! /bin/sh
 #
-# Copyright (C) 2002-2013 Free Software Foundation, Inc.
+# Copyright (C) 2002-2014 Free Software Foundation, Inc.
 #
 # This program is free software: you can redistribute it and/or modify
 # it under the terms of the GNU General Public License as published by
@@ -143,14 +143,14 @@ fi
 func_trace_autoconf ()
 {
   echo '\
-dnl disable macros which may abort autom4te
-m4_undefine([m4_assert])
-m4_undefine([m4_fatal])
-m4_undefine([m4_warn])
-m4_undefine([m4_errprintn])
-m4_undefine([m4_exit])
-m4_undefine([m4_include])
-m4_undefine([m4_esyscmd])
+dnl replace macros which may abort autom4te with a no-op variant
+m4_pushdef([m4_assert])
+m4_pushdef([m4_fatal])
+m4_pushdef([m4_warn])
+m4_pushdef([m4_errprintn])
+m4_pushdef([m4_exit])
+m4_pushdef([m4_include])
+m4_pushdef([m4_esyscmd])
 ' \
   | $AUTOM4TE --no-cache --language=Autoconf-without-aclocal-m4 \
 --trace=$1:\$% - $2 2/dev/null
diff --git i/gettext-tools/misc/gettextize.in
w/gettext-tools/misc/gettextize.in
index dbe4d1e..33299b9 100644
--- i/gettext-tools/misc/gettextize.in
+++ w/gettext-tools/misc/gettextize.in
@@ -1,6 +1,6 @@
 #! /bin/sh
 #
-# Copyright (C) 1995-1998, 2000-2013 Free Software Foundation, Inc.
+# Copyright (C) 1995-1998, 2000-2014 Free Software Foundation, Inc.
 #
 # This program is free software: you can redistribute it and/or modify
 # it under the terms of the GNU General Public License as published by
@@ -143,14 +143,14 @@ fi
 func_trace_autoconf ()
 {
   echo

Re: Example code bug

[Eric Blake]

On 08/16/2014 08:20 AM, Florian Mayer wrote:
 Hello m4 team,

[rearranging your mail a bit]

 
 I hope that it is an actual bug this time...

Not a bug per se, since, as you point out...

 
 I am aware of the existence of forloop2, which is listed in the example
 code
 directory, but I like this function for it's simplicity.

...the manual is trying to point out that the simple version is not
robust, and your example is proof of that.  However, looking at your
proposed patch:

existing:
 define(`_forloop', `$4'`ifelse($1, `$3', `', `define(`$1',
 incr($1))$0($@)')')

proposed:
 define(`_forloop', `$4'``''`ifelse($1, `$3', `', `define(`$1',
 incr($1))$0($@)')')

you are merely adding an empty quote to separate $4 from ifelse.  Which
seems simple enough to do.  I'll turn it into a formal patch soon enough.

-- 
Eric Blake   eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature

Re: Example code bug

[Eric Blake]

On 08/16/2014 08:35 AM, Eric Blake wrote:

 
 existing:
 define(`_forloop', `$4'`ifelse($1, `$3', `', `define(`$1',
 incr($1))$0($@)')')

Oops, I think the bug is on YOUR end, for mis-transcribing what is
already in the manual.  The manual actually says:

define(`_forloop',
   `$4`'ifelse($1, `$3', `', `define(`$1', incr($1))$0($@)')')

Note that it uses `$4`'ifelse..., where you typed `$4'`ifelse
Where the manual uses `', you incorrectly used '` as the separator
between the parameter expansion and the ifelse macro name.

 
 proposed:
 define(`_forloop', `$4'``''`ifelse($1, `$3', `', `define(`$1',
 incr($1))$0($@)')')
 
 you are merely adding an empty quote to separate $4 from ifelse.  Which
 seems simple enough to do.  I'll turn it into a formal patch soon enough.

Your proposed text matches what the manual already has, but with more
typing.  Remember, m4 does string concatenation, so it is joining the
strings $4, `', and ifelse..., for the end result of
$4`'ifelse... that matches what the manual already has.  No patch
necessary after all.

-- 
Eric Blake   eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature