[Top][All Lists]

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

m4_wrap behavior

From: Eric Blake
Subject: m4_wrap behavior
Date: Tue, 13 Jun 2006 12:47:08 +0000

The m4sugar documentation assumes that m4_wrap behaves in a
LIFO manner, since that is the behavior of GNU m4 1.4.x's m4wrap.
For example, the docs give this example of how not to use m4_wrap,
because the two wrapped outputs get concatenated and rescanned:

m4_define([foo], [Foo])
m4_define([bar], [Bar])
m4_define([foobar], [FOOBAR])

But POSIX requires m4wrap to behave in a FIFO manner, and with
POSIX, the above example would output barfoo rather than FOOBAR.
I plan to fix the bug in m4 2.0.  The question now is whether m4 2.0
should conditionalize LIFO vs. FIFO based on POSIXLY_CORRECT
(because existing uses of GNU m4 depend on LIFO), or whether this
corner case of m4sugar is not in heavy use, and the fix can be made
across the board.  Then, in m4sugar, we should just document
either that 1) m4_wrap has indeterminate ordering, or 2) m4_wrap
will always be LIFO or FIFO, regardless of the underlying m4wrap

As an idea of how to force m4_wrap ordering, this shows how
to give m4 1.4.4 FIFO ordering:

define([m4wrap_],[0])define([_m4wrap], defn([m4wrap]))dnl
define([m4wrap], [ifdef([m4wrap]m4wrap_,
[define([m4wrap]m4wrap_, defn([m4wrap]m4wrap_)[$1])],
[_m4wrap([define([m4wrap_], incr(m4wrap_))m4wrap]m4wrap_)dnl
define([m4wrap]m4wrap_, [$1])])])dnl

Eric Blake

reply via email to

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