Path: utzoo!yunexus!geac!syntron!jtsv16!uunet!lll-winken!lll-tis!ames!elroy!aero!sm.unisys.com!oberon!skat.usc.edu!blarson
From: blarson@skat.usc.edu (Bob Larson)
Newsgroups: comp.lang.c
Subject: Varargs implementation (was Re: Addresses of parameters)
Message-ID: <13102@oberon.USC.EDU>
Date: 27 Oct 88 06:34:27 GMT
Article-I.D.: oberon.13102
References: <8810111934.AA21941@ucbarpa.Berkeley.EDU> <8308@alice.UUCP> <23933@wlbr.EATON.COM> <1988Oct19.192548.28438@ateng.ateng.com> <35
Sender: news@oberon.USC.EDU
Reply-To: blarson@skat.usc.edu (Bob Larson)
Organization: USC AIS, Los Angeles
Lines: 25

In article <23385@amdcad.AMD.COM> tim@crackle.amd.com (Tim Olson) writes:
>How do you suppose varargs functions are implemented?  

In whatever machine/os/compiler specific way that is handy.

>They must take
>the address of the first parameter to "step through" the parameter list.

"must"?  I've written a couple of varargs implementations, and banged on
another.  I don't seem to recall any such requirement in the varargs specs,
and in fact that is not how I did it on the one I wrote for a system that
does pass the first two (with exceptions) arguments in registers.  Maybe
some do it that way, but that does not imply that that is the only way.

>Are you suggesting that varargs functions are not portable and should be
>avoided?

That was not my assertion, but note that ANSI decided vararg.h wasn't
portable enough so came up with stdarg.h.  (The compiler I mentioned
above would need internal support for stdarg.h while vararg.h can be added
as an afterthought.  Is this increased portability?)
-- 
Bob Larson	Arpa: Blarson@Ecla.Usc.Edu	blarson@skat.usc.edu
Uucp: {sdcrdcf,cit-vax}!oberon!skat!blarson
Prime mailing list:	info-prime-request%ais1@ecla.usc.edu
			oberon!ais1!info-prime-request