Re: patch: libm4.m4

["Lars J. Aas" <larsa at sim dot no>]

On Tue, Mar 14, 2000 at 06:09:56PM +0100, Akim Demaille wrote:
: | : Also, I'm attached to m4_default when that's what you mean.
: | 
: | Like this, then?
: | 
: | [pushdef([$1], [$2])_m4_for([$1], [$3], m4_default([$4], 1), [$5])dnl
: | popdef([$1])])
: 
: I would have gone up to
: 
: [pushdef([$1], [$2])dnl
: _m4_for([$1], [$3], m4_default([$4], 1), [$5])dnl
: popdef([$1])])

Are you ever pleased with anything I do ;)

: | : Oh, btw, m4_for was robust to stupid limits
: | : (from 10 to 1 step +1), be sure it remains safe when step is negative.
: | 
: | Don't understand what you mean.  If I did m4_for([i], 10, 1, [i ])
: | before, it wouldn't be safe - m4 goes wild...  The same is the
: | case now but in both directions, and if your step setting causes you
: | to miss the "last" limit, you're also spinning on into eternity...
: 
: Huh?  I was sure it was safe, but you are right.  The wrapper of
: _m4_for could handle this.

Well, if we're going to babysit the m4 coders, the m4_for() macro can be
invoked in tons of ways that will cause m4 to crash and burn.  Are we really
going to try to catch this?  And what if the usage doesn't make sense?  Should
we assume they they ment something else and go on - possibly causing delayed
errors, or should we exit directly?  Should we introduce m4_assert()?
What if m4_for is invoked like this:

  m4_for([i], 1, 16, [i], [m4_format([%d ], i)]) => 1 2 4 8 16 (hopefully)

We need to be inside the loop, analyzing current and previous state to try
to catch skipping LAST limits...

  Lars J