Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site alice.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!alice!ark
From: ark@alice.UucP (Andrew Koenig)
Newsgroups: net.lang.c
Subject: Re: varargs
Message-ID: <5336@alice.uUCp>
Date: Tue, 22-Apr-86 01:00:03 EST
Article-I.D.: alice.5336
Posted: Tue Apr 22 01:00:03 1986
Date-Received: Wed, 23-Apr-86 21:32:39 EST
References: <293@usc-oberon.UUCP>
Organization: Bell Labs, Murray Hill
Lines: 26

> Must va_alist be the only thing in the argument list?  (If this is not
> true, I don't see how to implement varargs with this compiler.)  (The
> example in the documentation seems to back up my assumption.)

Yes, va_alist must be the only thing in the argument list.  However,
you can use #define to make va_alist expand into something bigger.
That possibility, in fact, is the reason that va_alist must be the
only thing in the argument list.

> Is it leagal to pass a the rest of an argument list to another
> function expecting it?  If so, should it be passed as a pointer to a
> variable of type va_list?  (Without this capability, I supose I'll
> have to document this as a non-portable use of varargs.)

Yes, it is legal.  You may pass either a pointer to a va_list or
the entire va_list itself.  Passing the pointer is recommended, because
on some implementations the va_list may be quite large
and therefore slow to copy.  If you do pass the pointer, using
va_arg in the subroutine will advance the argument list pointer
as seen by the caller.

> I assume va_start be done in the original function.  (Dito the first
> va_alist comment.)  Does va_end have to be done in the original
> function also?  (va_end does nothing in my implementation.)

It should be.  (va_end does nothing in every implementation I've seen)