[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: va_list function portability doco
From: |
Akim Demaille |
Subject: |
Re: va_list function portability doco |
Date: |
Wed, 13 Feb 2002 13:46:40 +0100 |
User-agent: |
Gnus/5.090006 (Oort Gnus v0.06) XEmacs/21.4 (Common Lisp, i386-debian-linux) |
It seems like this guy never went in. Would you install it please?
----------------------------------------------------------------------
I don't suppose there's anything in the below which isn't a straight
consequence of the relevant standards, but perhaps a paragraph on the
traps might keep people out of trouble. The call-by-reference
behaviour on powerpc for instance seems to me a particular trap if one
hasn't encountered it before.
* autoconf.texi (Function Portability): Notes on va_list.
@item @code{va_list}
@c @fuindex va_list
@prindex @code{va_list}
Often @code{va_list} is just a pointer, but this is not always so.
Sometimes it's a structure (eg. @command{gcc} on Alpha), which means for
instance @code{NULL} should not be used. And sometimes it's an array
(eg. @command{gcc} on PowerPC, in some configurations), which means for
instance a @code{va_list} function parameter can be call-by-reference.
Applications may need to watch out for functions modifying the
@code{va_list} they're given (eg. @code{vsnprintf} in the GNU C Library
2.1 modifies it).
Any copying of a @code{va_list} should be done with @code{va_copy}, not
just @code{=}. @code{va_copy} is standard in C99 and hopefully will be
available on older compilers if @code{=} is not enough, though perhaps
as @code{__va_copy} (eg. @command{gcc} in strict C89 mode).
@code{#ifdef}s should suffice to test for these.
- Re: va_list function portability doco,
Akim Demaille <=