Bug in save-stack?

* Bug in save-stack?
@ 2005-02-15  2:23 Jim Blandy
  2005-02-15 13:53 ` Mikael Djurfeldt
  0 siblings, 1 reply; 3+ messages in thread
From: Jim Blandy @ 2005-02-15  2:23 UTC (permalink / raw)

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  <jimb@redhat.com>

	* 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)

_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

^ permalink raw reply	[flat|nested] 3+ messages in thread