[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: frozen files format 2
From: |
Gary V. Vaughan |
Subject: |
Re: frozen files format 2 |
Date: |
Fri, 23 Jun 2006 11:27:15 +0100 |
User-agent: |
Thunderbird 1.5.0.4 (Macintosh/20060530) |
Hi Eric!
Eric Blake wrote:
>>> 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.
>
> 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.
Agreed. This definitely deserves a TODO entry for m4-2.0, though I
think it beyond the scope of 1.4.x... unless of course, compatibility
turns out to need just a very obvious non-invasive change.
> 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.
Ick. What does POSIX have to say about this? Is Solaris M4 following
the standard here? Or striking out on its own?
> 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 "".
Agreed.
Cheers,
Gary.
--
Gary V. Vaughan ())_. address@hidden,gnu.org}
Research Scientist ( '/ http://blog.azazil.net
GNU Hacker / )= http://trac.azazil.net/projects/libtool
Technical Author `(_~)_ http://sources.redhat.com/autobook
signature.asc
Description: OpenPGP digital signature