Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84; site ucbvax.ARPA Path: utzoo!utcs!lsuc!pesnta!amd!dual!ucbvax!info-vax From: info-vax@ucbvax.ARPA Newsgroups: fa.info-vax Subject: Re: DEC C (2.0) Message-ID: <4970@ucbvax.ARPA> Date: Wed, 20-Feb-85 14:41:26 EST Article-I.D.: ucbvax.4970 Posted: Wed Feb 20 14:41:26 1985 Date-Received: Thu, 21-Feb-85 01:42:49 EST Sender: daemon@ucbvax.ARPA Organization: University of California at Berkeley Lines: 22 From: Gene Lege' I would suggest using the varargs.h macros, or implementing them if they are not available. There is no other completely portable way to pass a variable # of arguements to a "C" function, other than simply defining the called function to accept a large number of args and making sure you don't exceed this number. For instance, on a Pyramid 90x running OSx (UNIX), some of the args would be in the parameter registers, while others would be in the (logical) extension of the stack that is actually in RAM. The net result is that the stack is seperated into two components, the virtual addresses of which are non-contiguous. I believe that the varargs.h standard will be sanctioned by the forthcoming ANSI C standard. I am glad to see this discussion of the DEC VMS C compiler. We are working on a project that will need to run under both UNIX and VMS; Does anybody know of other pitfalls we should watch out for while doing the development under UNIX?