Re: m4_wrap behavior

[Eric Blake]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

>
> +** Autoconf no longer depends on whether m4wrap is FIFO (as Posix requires)
> +  or LIFO (as in GNU m4 1.4.x).  GNU m4 2.0 is expected to conform to Posix
> +  here, so m4wrap/m4_wrap users should no longer depend on LIFO behavior.

A note - I've been trying to clean up m4, so that in its documentation, it
is called 'm4' if it is the program, and 'GNU M4' if it is the package
(similar to 'autoconf' vs. 'GNU Autoconf').  We ought to be consistent
here, and call it GNU M4 2.0 or GNU M4 1.4.x.

> -You are encouraged to end @var{text} with @samp{[]}, so that there are
> -no risks that two consecutive invocations of @code{m4_wrap} result in an
> -unexpected pasting of tokens, as in
> +Posix requires arguments of multiple @code{m4wrap} calls to be
> +reprocessed at @acronym{EOF} in the same order as the original calls.
> address@hidden M4 versions through 1.4.x, however, reprocess them in
> +reverse order.  Your code should not depend on the order.

There was also the question of whether m4sugar should reject calls to
m4_wrap with multiple arguments, since that is not Posix-specified (GNU m4
1.4.x concatenates each argument together with a space, but traditional
implementations only save the first argument).  An approach for that is:

m4_define([m4_wrap],
[m4_if(m4_eval([$# > 1])), [1], [m4_fatal([$0: too many args])],
[m4_builtin([m4wrap], address@hidden)])])

But I don't think that is a show-stopper; if anything, 2.60 should just
document that m4_wrap is only safe with one argument.

- --
Life is short - so eat dessert first!

Eric Blake             address@hidden
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.1 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEl+Vt84KuGfSFAYARAht8AKCSI2QZVS5uou2CY9sbgkwXWOnKBQCgmmYr
1P0iDJpWl6Zcw4DrhWplLg8=
=PIb/
-----END PGP SIGNATURE-----