From mboxrd@z Thu Jan  1 00:00:00 1970
To: 9fans@cse.psu.edu
Subject: Re: [9fans] stdarg & va_copy
From: "Russ Cox" <rsc@swtch.com>
Date: Thu, 24 Jan 2008 17:39:02 -0500
In-Reply-To: <1709339a44febca19fd2e2f36c780d0d@quanstro.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Message-Id: <20080124223857.C0BAA1E8C1C@holo.morphisms.net>
Topicbox-Message-UUID: 377fe8c0-ead3-11e9-9d60-3106f5b1d025

> i didn't see anything in the definition that would make va_copy
> wrong given the plan 9 definition of va_list.  is there a particular
> case on plan 9 that would be a problem?

it might make sense to *have* va_copy, but since plan 9
programs don't use va_copy, there's no need to provide
an implementation.  and honestly, the fewer people who
use va_copy, the better.

> but plan 9 does have va_start and va_end.  wouldn't make sense
> to have va_copy as well?

plan 9 makes no claims of being C99 compliant,
although it happens to have a few of the same extensions.
va_start, va_end, and va_arg are from an earlier standard.
those (in particular va_arg) provide useful functionality.
va_copy does not.

like i said, if you need it, it's easy to put a #define
in your own compatibility headers.  if you don't
need it, don't worry about it.

russ