[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: m4_wrap behavior

From: Eric Blake
Subject: Re: m4_wrap behavior
Date: Tue, 20 Jun 2006 06:09:17 -0600
User-agent: Thunderbird (Windows/20060516)

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_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
Version: GnuPG v1.4.2.1 (Cygwin)
Comment: Public key at
Comment: Using GnuPG with Mozilla -


reply via email to

[Prev in Thread] Current Thread [Next in Thread]