<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 2 October 2015 at 22:07, Aaron Ballman <span dir="ltr"><<a href="mailto:aaron@aaronballman.com" target="_blank">aaron@aaronballman.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Fri, Oct 2, 2015 at 4:01 PM, mats petersson <<a href="mailto:mats@planetcatfish.com">mats@planetcatfish.com</a>> wrote:<br>
> Since "varargs" often involve some kind of special passing mechanisms [I've<br>
> seen implementations that build data block and pass a pointer to that,<br>
> rather than passing on the stack, for example], or additional code in the<br>
> recipient function, I would say that `f2()` does not mean `f2(...)`.<br>
<br>
</span>I kind of wondered if that was the case. If that's reality, perhaps we<br>
may want to consider naming it FunctionDecl::hasVarArgs() or something<br>
that specifies the difference is in whether we need to care about<br>
packaging up the argument list so it can be used with va_start() and<br>
friends?<br></blockquote><div><br>My understanding of the meaning of `isVariadic` is indeed "needs to use va_* to get arguments". <br><br>I believe it's technically valid to do something like:<br><br>void f2();<br><br>....<br>    f2(42);<br>....<br><br>voif f2(int x)<br>{</div><div>    ... use x ... <br>}<br><br>and no special code should be required. Of course, the results of changing `f2(42);` int `f2(4.2);` or `f2("foo");` and retaining the `int x` parameter will lead to undefined behaviour, and compiler can do anything it likes with that... :)<br><br>--</div><div>Mats</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class="HOEnZb"><font color="#888888"><br>
~Aaron<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
><br>
> --<br>
> Mats<br>
><br>
> On 2 October 2015 at 20:16, Aaron Ballman via cfe-commits<br>
> <<a href="mailto:cfe-commits@lists.llvm.org">cfe-commits@lists.llvm.org</a>> wrote:<br>
>><br>
>> Given the following two function declarations:<br>
>><br>
>> void f1(...);<br>
>> void f2();<br>
>><br>
>> It makes sense to me that isVariadic() returns true for f1 in both C<br>
>> and C++. It makes sense to me that isVariadic() returns false for f2<br>
>> in C++. I am confused as to why it returns false instead of true for<br>
>> C, however.<br>
>><br>
>> In C11, 6.7.6.3p9 states: If the list terminates with an ellipsis (,<br>
>> ...), no information about the number or types of the parameters after<br>
>> the comma is supplied.<br>
>><br>
>> p14 states, in part: "The empty list in a function declarator that is<br>
>> not part of a definition of that function specifies that no<br>
>> information about the number or types of the parameters is supplied."<br>
>><br>
>> It seems to me that for function *declarations* (not definitions),<br>
>> isVariadic() should return true for f2 in C. Is there a reason it<br>
>> doesn't currently behave that way, or is this a bug?<br>
>><br>
>> I ask because I was writing an AST matcher for isVariadic() for an<br>
>> in-progress checker, but the checker was failing to catch that f2 was<br>
>> a variadic function. I am not certain whether<br>
>> FunctionDecl::isVariadic() should be changed, whether the AST matcher<br>
>> isVariadic() should be smarter about C code, or whether the checker<br>
>> itself needs to be smarter about this particular behavior in C code.<br>
>> My gut reaction is that FunctionDecl::isVariadic() has a bug, but from<br>
>> looking at code elsewhere, everything seems to assume isVariadic()<br>
>> implies the ellipsis, which makes me think I just need to make my<br>
>> checker smarter.<br>
>><br>
>> Thanks!<br>
>><br>
>> ~Aaron<br>
>> _______________________________________________<br>
>> cfe-commits mailing list<br>
>> <a href="mailto:cfe-commits@lists.llvm.org">cfe-commits@lists.llvm.org</a><br>
>> <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits</a><br>
><br>
><br>
</div></div></blockquote></div><br></div></div>