Bug in save-stack?

[Jim Blandy]

Looking at the definition of save-stack in boot-9.scm, I notice that,
in all but one of the cases, the elements of NARROWING are passed
after an even number of cutting arguments, but in the #t case, they
are passed after an odd number of cutting arguments.  In other words,
when the stack id is #t, the first argument passed to save-stack is
treated as an OUTER-CUT, not an INNER-CUT, as it would be for any
other stack id.

I don't know what a stack-id of #t is supposed to mean; I can't find
it documented or being used anywhere.  But the behavior of save-stack
when the stack-id is #t looks accidental.  Would something like the
below be appropriate?

If this is right, someone knowledgeble should also document what a
stack id of #t is supposed to mean.  Otherwise, that clause should be
deleted.

2005-02-14  Jim Blandy  <address@hidden>

        * boot-9.scm (save-stack): When (stack-id #t) is #t, don't neglect
        to pass an OUTER-CUT argument corresponding to the second
        INNER-CUT argument.

*** boot-9.scm.~1.340.~ 2004-11-30 19:02:24.000000000 -0500
--- boot-9.scm  2005-02-14 21:19:26.000000000 -0500
***************
*** 2424,2430 ****
                ((tk-stack)
                 (apply make-stack #t save-stack tk-stack-mark #t 0 narrowing))
                ((#t)
!                (apply make-stack #t save-stack 0 1 narrowing))
                (else
                 (let ((id (stack-id #t)))
                   (and (procedure? id)
--- 2424,2430 ----
                ((tk-stack)
                 (apply make-stack #t save-stack tk-stack-mark #t 0 narrowing))
                ((#t)
!                (apply make-stack #t save-stack 0 1 0 narrowing))
                (else
                 (let ((id (stack-id #t)))
                   (and (procedure? id)