Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site utah-gr.UUCP
Path: utzoo!linus!philabs!cmcl2!seismo!utah-cs!utah-gr!thomas
From: thomas@utah-gr.UUCP (Spencer W. Thomas)
Newsgroups: net.lang.c
Subject: Re: gripe: variable arg lists
Message-ID: <1254@utah-gr.UUCP>
Date: Fri, 23-Nov-84 16:30:56 EST
Article-I.D.: utah-gr.1254
Posted: Fri Nov 23 16:30:56 1984
Date-Received: Sat, 24-Nov-84 21:04:52 EST
References: <348@gitpyr.UUCP> <3106@alice.UUCP> <394@ucsfcgl.UUCP>
Reply-To: thomas@utah-gr.UUCP (Spencer W. Thomas)
Organization: Univ of Utah CS Dept
Lines: 29
Summary: 

In article <394@ucsfcgl.UUCP> katzung@ucsfcgl.UUCP (Brian Katzung) writes:
>> But there is a standard method of dealing with variable argument lists.
>> 	#include <varargs.h>
>> The contents of the file differ from machine to machine, but the `entry points'
>> are standard.
>> 
>(I didn't see the original article so I'm not sure what was said.
>My apologies if I'm repeating something.)
>
>The "standard method" can't always be applied.  As far as I know, it
>is impossible to do under some implementations (I'd be delighted to
>have somebody prove me wrong by providing a non-trivial solution (ie,
>one that doesn't consist of separate entry points)).
>
>The problem arises on systems like ZILOG that put some arguments in
>registers (it may speed up execution a little, but it slows me
>down a lot).

The Pyramid is an example of a system that puts args in registers, but
they were perfectly able to write a "varargs" package.  The secret is a
little subroutine that knows where arguments are to be found and snarfs
up the first "n" of them from the registers and the rest from the stack
(or wherever), and builds a contiguous memory array of them.  Works
fine, and their implementation of sprintf (using varargs) runs fine on
their system, and on the Vax (the two places I've tried it).  I think
that with sufficient "cleverness", one can always get away with this
type of trick.

=Spencer