Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site pur-phy.UUCP
Path: utzoo!linus!decvax!harpo!eagle!mhuxt!mhuxi!cbosgd!ihnp4!ixn5c!inuxc!pur-ee!CSvax:Pucc-H:pur-phy!crl
From: crl@CSvax:Pucc-H:pur-phy.UUCP
Newsgroups: net.emacs
Subject: bug in arg passing
Message-ID: <866@pur-phy.UUCP>
Date: Thu, 11-Aug-83 11:28:53 EDT
Article-I.D.: pur-phy.866
Posted: Thu Aug 11 11:28:53 1983
Date-Received: Sat, 13-Aug-83 02:40:18 EDT
Organization: Purdue Univ. Physics Dept., W. Lafayette, IN
Lines: 32

I have found a bug in the argument passing code of (non-Unipress) EMACS.
Granted, I run a PDP-11 version, but I have tested it on Vaxen, and it
is still there.  The problem is evidenced by the following mlisp. Define
two functions:
(defun (foo a b
	   (setq a (arg 1))
	   (setq b (arg 2))
	   (message a b)
	   (novalue))
       (bar a b
	   (setq a "foo")
	   (setq b "bar")
	   (foo a b)
	   (novalue))
)
Call bar.  You would expect the message "foobar" to appear.  What happens
is that "00" appears.  Call (foo "foo" "bar")--you get "foobar".  Change
the variables 'a' and 'b' in bar to 'c' and 'd'--you get "foobar" now.

The problem is that in constructing the progn that is foo, the new
local variables 'a' and 'b' overlay the variables in bar.  The (arg)
call simply tries to evaluate the variable 'a', not knowing that the
new declaration has hidden the old.  Since the new one is automatically
initialized to 0, you get the message "00" instead.  I don't immediately
see a good way to handle this.  It means that all your "subroutines"
must use local variables that will never conflict.  For those of you
who have looked at the source, perhaps arguments should be evaluated
on the call and changed into StringNodes?

Charles LaBrec
pur-ee!Physics:crl
purdue!Physics:crl