bug-m4
[Top][All Lists]
Advanced

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

Re: frozen files format 2


From: Eric Blake
Subject: Re: frozen files format 2
Date: Thu, 22 Jun 2006 21:54:52 +0000 (UTC)
User-agent: Loom/3.14 (http://gmane.org/)

Gary V. Vaughan <gary <at> gnu.org> writes:

> 
> > Next, should we allow partial input?  Right now, m4 chokes if a file is in
> > the middle of a macro, even if the next file could complete the story:
> > $ echo "len(" > c.m4
> > $ echo "abc)" > d.m4
> > $ m4 c.m4 d.m4
> > NONE:0: m4: ERROR: EOF in argument list
> > $ cat c.m4 d.m4 | m4
> > 3
> > $ m4 -F c.m4f c.m4
> > NONE:0: m4: ERROR: EOF in argument list
> > $
> > 
> > But since we also refuse to create c.m4f, our behavior of freezing matches
> > our normal behavior.  I'll have to check how Solaris behaves in this case,
> > but right now, I don't think I'm inclined to change behavior here.
> 
> ACK.  An interesting feature to add post-2.0 though 

Ouch.  We aren't compatible here, without adding the feature of partial input 
across EOF.  With Solaris 8:

$ echo "m4wrap(\`abc)
> ')len(" | m4
NONE:0: m4: ERROR: EOF in argument list
$ echo "m4wrap(\`abc)
> ')len(" | /usr/ccs/bin/m4
3
$ echo "len(" > a.m4
$ echo "abc)" > b.m4
$ m4 a.m4 b.m4
NONE:0: m4: ERROR: EOF in argument list
$ /usr/ccs/bin/m4 a.m4 b.m4
3
$

But at least we are consistent in that the transition at EOF of one file to the 
next (or to wrapped text) inserts an implicit quoted empty string, rather than 
trying to continue growing the current name found prior to EOF (note that when 
changing from one file to the next, this example is not completely kosher, 
since m4 need only operate on text files, which POSIX defines to end in a 
newline; but the example can also be written in a kosher manner across the 
transition between two recursion levels of m4wrap):

$ printf "define(\`aa', \`BB')define(\`a',\`A')dnl
> a" > a.m4
$ echo a | m4 a.m4 -  # Two distinct `a's were parsed, not `aa'
AA
$ echo a | /usr/ccs/bin/m4 a.m4 -
AA
$ echo "m4wrap(\`a
> ')dnl" | m4 - a.m4  # Likewise
AA
$ echo "m4wrap(\`a
> ')dnl" | /usr/ccs/bin/m4 - a.m4  # Likewise
AA

If either m4 had concatenated macro names across EOF into the next input 
source, then the output would be BB instead of AA.

Then there is the matter of concatentation of defn's, where we are still not 
compatible, even on CVS head (although at least CVS head allows multiple 
arguments to defn, where m4 1.4.x did not):
$ /usr/ccs/bin/m4
define(`foo', defn(`divnum')defn(`divnum'))foo
00
define(`bar', defn(`divnum', `divnum'))bar
00
define(`f1', a`'defn(`divnum'))f1
a0
define(`f2', defn(`divnum')a)f2
0a
^D
$ m4
define(`foo', defn(`divnum')defn(`divnum'))foo
0
define(`bar', defn(`divnum', `divnum'))bar
0
define(`f1', a`'defn(`divnum'))f1
a
define(`f2', defn(`divnum')a)f2
0
^D

Ouch again - Solaris allows a macro to expand to a stack of tokens, but we are 
only capturing the first token on the stack.  And our symbol table is not 
currently set up to store a stack of tokens with a single macro name.

Here's another thought experiment:

$ /usr/ccs/bin/m4
m4wrap(`define(a,')dnl
m4wrap(defn(`divnum'))dnl
m4wrap(`)a
')dnl
^D
$ m4   # m4wrap is still LIFO; so this puts the same data on the wrap stack
m4wrap(`)a
')dnl
m4wrap(defn(`divnum'))dnl
m4wrap(`define(a,')dnl
^D
$

Here, neither version preserved the builtin's token; the m4wrap string was 
evaluated as though it were strictly textual.  I think in -G/--traditional, we 
should behave likewise for compatibility, but perhaps in GNU mode we should let 
the wrap stack hold builtin tokens as well as text, so that the output would 
be "0" instead of "".

-- 
Eric Blake






reply via email to

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