Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site fortune.UUCP
Path: utzoo!linus!philabs!cmcl2!floyd!clyde!ihnp4!fortune!shah
From: shah@fortune.UUCP
Newsgroups: net.micro.68k
Subject: Re: Re: nargs - (nf)
Message-ID: <2113@fortune.UUCP>
Date: Wed, 28-Dec-83 04:03:12 EST
Article-I.D.: fortune.2113
Posted: Wed Dec 28 04:03:12 1983
Date-Received: Fri, 30-Dec-83 00:32:13 EST
Sender: notes@fortune.UUCP
Organization: Fortune Systems, Redwood City, CA
Lines: 28

#R:sii:-36300:fortune:6600006:000:1044
fortune!shah    Dec 27 22:21:00 1983

*
    I agree with Mark Mallet (sii!mem); nargs should be used with
caution.  It is a simple hack that works well if your compiler is
not too tricky smart and if it is used in a well understood context.
That is, the caller of nargs() should *know* what kind of values may
be passed to it.

    The version you saw was written for a co-routine package.  We
wanted to create co-routines out of any routine (with ANY number of
arguments).  As an example, you can create a co-routine out of
routine "foo" with 3 arguments by saying

    fooProcess = createProc(stackAddress, stackSize, deathHandler,
			    foo, arg1, arg2, arg3);

Later on when you "resume(fooProcess)" it is as if you *called* foo
with arg1, arg2, arg3.  Our nargs() is used by routine createProc in
copying arguments arg1, arg2, etc. to the co-routine stack.

    Ofcourse, nargs() *has* to stay in tune with the compiler.  If
that is not possible you have to resort to really messy hacks (as
opposed to clean hacks) in such applications.
						     -- Bakul
						fortune!shah