Eric Blake wrote:
> Meanwhile, is it worth patching autoconf/lib/autoheader.m4 to complain when
> $2 of AH_VERBATIM is empty, so this mistake is less likely to occur in the
> future?
This would be welcome. Something like this (untested)?
*** autoheader.m4.bak 2005-05-14 09:00:39.0 +0200
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
