Re: frozen files format 2

[Gary V. Vaughan]

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