<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Fri, Oct 5, 2018 at 11:52 AM John Brawn via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">> I've found that clang v7 treats va_arg, at least differently from gcc<br>
> (and c standard says it should accept argument with one void). Clang<br>
> does not accept va_arg(...,void).<br>
<br>
GCC from version 6 onwards (and perhaps earlier) also gives an error<br>
for this. And I don't see anything in the C standard to say it should<br>
accept void as an argument: looking at section 7.15.1.1 paragraph 2<br>
of C99 it says:<br>
<br>
If there is no actual next argument, or if type is not compatible with<br>
the type of the actual next argument (as promoted according to the<br>
default argument promotions), the behavior is undefined, except for the<br>
following cases:<br>
- one type is a signed integer type, the other type is the corresponding<br>
unsigned integer type, and the value is representable in both types;<br>
- one type is pointer to void and the other is a pointer to a character<br>
type.<br>
<br>
void is not compatible with any type, so doing va_arg(something, void) is<br>
undefined behaviour (though I wouldn't be surprised if something elsewhere<br>
makes it invalid to use an incomplete type here for some other reason).<br></blockquote><div>The argument needs to be made that it is impossible to pass a void expression as an argument to a function call. This happens to be true: argument passing defers to simple assignment, and the latter is not allowed for void.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
If it were to be permitted I also don't see anything meaningful that the<br>
compiler could do with such a va_arg call, other than to say "void = nothing<br>
therefore va_arg(something, void) means don't consume an argument" in<br>
which case the solution is just to remove the va_arg call.<br>
<br>
John<br>
<br>
> -----Original Message-----<br>
> From: llvm-dev [mailto:<a href="mailto:llvm-dev-bounces@lists.llvm.org" target="_blank">llvm-dev-bounces@lists.llvm.org</a>] On Behalf Of<br>
> Qiantan Hong via llvm-dev<br>
> Sent: 04 October 2018 23:22<br>
> To: <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
> Subject: [llvm-dev] va_arg macro<br>
> <br>
> Hi,<br>
> <br>
> New here, not mean to be spam. If I'm doing something wrong please just<br>
> tell me.<br>
> <br>
> I've found that clang v7 treats va_arg, at least differently from gcc<br>
> (and c standard says it should accept argument with one void). Clang<br>
> does not accept va_arg(...,void).<br>
> When I was trying to build redis I got this:<br>
> <br>
> hiredis.c:799:31: error: second argument to 'va_arg' is of incomplete<br>
> type<br>
> 'void'<br>
> va_arg(ap,void);<br>
> <br>
> I then write a work around by replacing `#define va_arg(ap, type)<br>
> __builtin_va_arg(ap, type)` with those line to stdarg.h (In my<br>
> environment, the path is<br>
> /usr/local/Cellar/llvm/7.0.0/lib/clang/7.0.0/include):<br>
> <br>
> #define __kscarlet_transform_cat_(x,y) x##y<br>
> #define __kscarlet_transform_cat(x,y) __kscarlet_transform_cat_(x,y)<br>
> #define __kscarlet_transform_void() )()__kscarlet_transform_n_(<br>
> #define __kscarlet_transform_e(...) __VA_ARGS__<br>
> #define __kscarlet_transform_e_(...) __VA_ARGS__<br>
> #define __kscarlet_transform_n(...)<br>
> #define __kscarlet_transform_n2(...) char<br>
> #define __kscarlet_transform_n_(...) __kscarlet_transform_n2<br>
> #define __kscarlet_transform_void_(...) __kscarlet_transform_e<br>
> #define va_arg(ap,type)<br>
> __builtin_va_arg(ap,__kscarlet_transform_e_(__kscarlet_transform_void_<br>
> __kscarlet_transform_n()(__kscarlet_transform_cat(<br>
> __kscarlet_transform_,type)()))(type))<br>
> <br>
> This solves the problem, though it polluted global namespace. Do you<br>
> have any idea to patch it / whether it should be patched?<br>
> <br>
> Best,<br>
> BlueFlo0d<br>
> <br>
> <br>
<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div></div>