Eric Blake <[EMAIL PROTECTED]> writes:
> In the case of va_copy, POSIX defines it to have void value, so trying to
> use va_copy for its result is invalid, and the missing parenthesis can't
> affect a compliant program.
"(void) va_copy (foo, bar)" is a counterexample to that claim.
(Never underes
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Paul Eggert on 7/1/2006 3:27 PM:
> [EMAIL PROTECTED] (Eric Blake) writes:
>
>> +#define gl_va_copy(a,b) (a) = (b)])
>
> I'm not familiar with this package, but surely that should be ((a) =
> (b)), not (a) = (b).
In the case of va_copy,
[EMAIL PROTECTED] (Eric Blake) writes:
> +#define gl_va_copy(a,b) (a) = (b)])
I'm not familiar with this package, but surely that should be ((a) =
(b)), not (a) = (b).
Andreas Büning nexgo.de> writes:
>
> Since $gl_cv_func___va_copy != yes the code after else is executed
> and "#define va_copy gl_va_copy" is inserted into config.h. Obviously,
> it is intended to also define gl_va_copy in this case but AH_VERBATIM
> is called with wrong syntax so that this stat
Eric Blake wrote:
>
> [Moving from m4-patches to bug-gnulib]
>
> > > [recommendation to run gnulib-tool]
> > Done. Then the linker complained about 'gl_va_copy' being an unresolved
> > external. Reason is that va_copy is defined to gl_va_copy in config.h.
> > gl_va_copy is supposed to be defined
[Moving from m4-patches to bug-gnulib]
> >
> > You need to have a recent CVS checkout of gnulib available, and rerun m4's
> > bootstrap with gnulib-tool either on your path or located in the
> > environment variable GNULIB_TOOL. (Hmm, I probably ought to add a HACKING
> > document for CVS only t
