This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Document va_copy in preference to __va_copy
- From: "Carlos O'Donell" <carlos at systemhalted dot org>
- To: "Joseph S. Myers" <joseph at codesourcery dot com>
- Cc: libc-alpha at sourceware dot org
- Date: Mon, 23 Jul 2012 20:54:47 -0400
- Subject: Re: Document va_copy in preference to __va_copy
- References: <Pine.LNX.4.64.1207202318520.357@digraph.polyomino.org.uk>
On Fri, Jul 20, 2012 at 7:19 PM, Joseph S. Myers
<joseph@codesourcery.com> wrote:
> The glibc manual documents __va_copy, a GNU extension, rather than
> va_copy, a standard C99 feature. I propose this patch to prefer
> va_copy in the documentation and only refer to __va_copy as a
> secondary matter, since I don't think compatibility with compilers
> before GCC 3.0 is particularly relevant to most readers of this manual
> now. (Note that nowadays the GNU Coding Standards allow relying on
> C99 features.)
>
> Tested with "make info" and "make pdf".
>
> 2012-07-20 Joseph Myers <joseph@codesourcery.com>
>
> * manual/lang.texi (__va_copy): Document primarily as ISO C99
> va_copy. Document allowing for unavailable va_copy only as
> pre-C99 compatibility.
> * manual/string.texi (Copying and Concatenation): Use va_copy
> instead of __va_copy in concat example.
>
This looks good to me and matches what is already in the
linux manpage for va_copy.
The manpage actually says "Some systems that do not supply
va_copy() have __va_copy instead, since that was the name
used in the draft proposal."
Cheers,
Carlos.