autobook_51.html

Autoconf使用手册

  va_list ap;
  char *arg;

  va_start (ap);
  ...
  arg = va_arg (ap, char *);
  ...
  va_end (ap);

  return arg ? strlen (arg) : 0;
}
</pre></td></tr></table></P><P>

ANSI C provides a similar API, imported with <SAMP>`#include
&#60;stdarg.h&#62;'</SAMP>, though it cannot express  a variadic function with no named
arguments such as the one above.  In practice, this isn't a problem
since you always need at least one parameter, either to specify the
total number of arguments somehow, or else to mark the end of the
argument list.  An ANSI variadic function definition looks like
this:
</P><P>

<TABLE width=100%><tr><td>&nbsp;</td><td class=example bgcolor=#6688aa><br><pre>int
functionname (char *format, ...)
{
  va_list ap;
  char *arg;

  va_start (ap, format);
  ...
  arg = va_arg (ap, char *);
  ...
  va_end (ap);

  return format ? strlen (format) : 0;
}
</pre></td></tr></table></OL>
<P>

Except in very rare cases where you are writing a low level project
(GCC for example), you probably don't need to worry about K&#38;R
compilers too much.  However, supporting them can be very easy, and if
you are so inclined, can be handled either by employing the
<CODE>ansi2knr</CODE> program supplied with Automake, or by careful use of
the preprocessor.
</P><P>

Using <CODE>ansi2knr</CODE> in your project is described in some detail in
section `Automatic de-ANSI-fication' in <CITE>The Automake Manual</CITE>, but
boils down to the following:
</P><P>

<UL>
<LI>
Add this macro to your <TT>`configure.in'</TT> file:
<P>

<TABLE width=100%><tr><td>&nbsp;</td><td class=example bgcolor=#6688aa><br><pre>AM_C_PROTOTYPES
</pre></td></tr></table></P><P>

<LI>
Rewrite the contents of <SAMP>`LIBOBJS'</SAMP> and/or  <SAMP>`LTLIBOBJS'</SAMP> in
the following fashion:
<P>

<TABLE width=100%><tr><td>&nbsp;</td><td class=example bgcolor=#6688aa><br><pre># This is necessary so that .o files in LIBOBJS are also built via
# the ANSI2KNR-filtering rules.
Xsed='sed -e "s/^X//"'
LIBOBJS=`echo X"$LIBOBJS"|\
	[$Xsed -e 's/\.[^.]* /.\$U&#38; /g;s/\.[^.]*$/.\$U&#38;/']`
</pre></td></tr></table></UL>
<P>

Personally, I dislike this method, since every source file is filtered
and rewritten with ANSI function prototypes and declarations
converted to K&#38;R style adding a fair overhead in additional files in
your build tree, and in compilation time.  This would be reasonable were
the abstraction sufficient to allow you to forget about K&#38;R entirely,
but <CODE>ansi2knr</CODE> is a simple program, and does not address any of
the other differences between compilers that I raised above, and it
cannot handle macros in your function prototypes of definitions.  If you
decide to use <CODE>ansi2knr</CODE> in your project, you must make the
decision before you write any code, and be aware of its limitations as
you develop.
</P><P>

For my own projects, I prefer to use a set of preprocessor macros along
with a few stylistic conventions so that all of the differences between
K&#38;R and ANSI compilers are actually addressed, and so that the
unfortunate few who have no access to an ANSI compiler (and who
cannot use GCC for some reason) needn't suffer the overheads of
<CODE>ansi2knr</CODE>.
</P><P>

The four differences in style listed at the beginning of this subsection
are addressed as follows:
</P><P>

<OL>
<LI>
The function prototype argument lists are declared inside a <CODE>PARAMS</CODE>
macro invocation so that K&#38;R compilers will still be able to compile the
source tree.  <CODE>PARAMS</CODE> removes ANSI argument lists from
function prototypes for <FONT SIZE="-1">K&#38;R</FONT> compilers.  Some developers
continue to use <CODE>__P</CODE> for this purpose, but strictly speaking,
macros starting with <SAMP>`_'</SAMP> (and especially <SAMP>`__'</SAMP>) are reserved
for the compiler and the system headers, so using <SAMP>`PARAMS'</SAMP>, as
follows, is safer:
<P>

<TABLE width=100%><tr><td>&nbsp;</td><td class=example bgcolor=#6688aa><br><pre>#if __STDC__
#  ifndef NOPROTOS
#    define PARAMS(args)      args
#  endif
#endif
#ifndef PARAMS
#  define PARAMS(args)        ()
#endif
</pre></td></tr></table></P><P>

This macro is then used for all function declarations like this:
</P><P>

<TABLE width=100%><tr><td>&nbsp;</td><td class=example bgcolor=#6688aa><br><pre>extern int functionname PARAMS((const char *parameter));
</pre></td></tr></table></P><P>

<LI>
With the <CODE>PARAMS</CODE> macro is used for all function declarations,
ANSI compilers are given all the type information they require to
do full compile time type checking.  The function definitions
proper must then be declared in K&#38;R style so that K&#38;R compilers don't
choke on ANSI syntax.  There is a small amount of overhead in
writing code this way, however:   The ANSI compile time type
checking can only work in conjunction with K&#38;R function definitions if
it first sees an ANSI function prototype.  This forces you to
develop the good habit of prototyping <EM>every single</EM> function in
your project.  Even the <CODE>static</CODE> ones.
<P>

<LI>
The easiest way to work around the lack of <CODE>void *</CODE> pointers, is to
define a new type that  is conditionally set to <CODE>void *</CODE> for
ANSI compilers, or <CODE>char *</CODE> for <FONT SIZE="-1">K&#38;R</FONT> compilers.  You
should add the following to a common header file:
<P>

<TABLE width=100%><tr><td>&nbsp;</td><td class=example bgcolor=#6688aa><br><pre>#if __STDC__
typedef void *void_ptr;
#else /* !__STDC__ */
typedef char *void_ptr;
#endif /* __STDC__ */
</pre></td></tr></table></P><P>

<LI>
The difference between the two variadic function APIs pose a
stickier problem, and the solution is ugly.  But it <EM>does</EM> work.
First you must check for the headers in <TT>`configure.in'</TT>:
<P>

<TABLE width=100%><tr><td>&nbsp;</td><td class=example bgcolor=#6688aa><br><pre>AC_CHECK_HEADERS(stdarg.h varargs.h, break)
</pre></td></tr></table></P><P>

Having done this, add the following code to a common header file:
</P><P>

<TABLE width=100%><tr><td>&nbsp;</td><td class=example bgcolor=#6688aa><br><pre>#if HAVE_STDARG_H
#  include &#60;stdarg.h&#62;
#  define VA_START(a, f)        va_start(a, f)
#else
#  if HAVE_VARARGS_H
#    include &#60;varargs.h&#62;
#    define VA_START(a, f)      va_start(a)
#  endif
#endif
#ifndef VA_START
  error no variadic api
#endif
</pre></td></tr></table></P><P>

You must now supply each variadic function with both a K&#38;R and an
ANSI definition, like this:
</P><P>

<TABLE width=100%><tr><td>&nbsp;</td><td class=example bgcolor=#6688aa><br><pre>int
#if HAVE_STDARG_H
functionname (const char *format, ...)
#else
functionname (format, va_alist)
     const char *format;
     va_dcl
#endif
{
  va_alist ap;
  char *arg;

  VA_START (ap, format);
  ...
  arg = va_arg (ap, char *);
  ...
  va_end (ap);

  return arg : strlen (arg) ? 0;
}
</pre></td></tr></table></OL>
<P>

<A NAME="A Simple Shell Builders Library"></A>
</TR></TABLE>
<BR>  
<FONT SIZE="-1">
This document was generated
by <I>Gary V. Vaughan</I> on <I>September, 12  2004</I>
using <A HREF="http://www.mathematik.uni-kl.de/~obachman/Texi2html
"><I>texi2html</I></A>

</BODY>
</HTML>