[Top][All Lists]
[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