<div dir="ltr">On Tue, Oct 1, 2013 at 8:27 PM, Edward Diener <span dir="ltr"><<a href="mailto:eldlistmailingz@tropicsoft.com" target="_blank">eldlistmailingz@tropicsoft.com</a>></span> wrote:<br><div class="gmail_extra">
<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="im">On 10/1/2013 2:16 PM, Nico Rieck wrote:<br>

<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
On 30.09.2013 05:29, Edward Diener wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
I could not find anything in the C++11 standard about variadic functions<br>
and calling conventions. Is this a "bug" with clang under Windows or<br>
should Boost.TypeTraits not try to allow __fastcall in this situation<br>
when compiling with clang under Windows ?<br>
</blockquote>
<br>
I think it's a defect in both. Boost should drop the overloaded vararg<br>
is_function_ptr_tester specializations with non-standard calling<br>
conventions as they are never used. When MSVC encounters a vararg<br>
function with stdcall/fastcall it silently converts it to cdecl.<br>
</blockquote>
<br></div>
is there a way to test that this is what it actually does ?</blockquote><div><br></div><div>First, compiling the code "void __fastcall foo() { }" produces the symbol ?foo@@YAXZZ which demangles to 'void __cdecl foo(...)'.</div>
<div><br></div><div>Second, you can call it and verify that the assembly is adhering to the usual C calling convention.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class="im">
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Though<br>
for compatibility with (broken) MSVC code Clang should match that<br>
behavior if desired.<br>
</blockquote>
<br></div>
The issue is that MSVC will accept the declaration without a compiler error as part of its extensions no matter what it may silently do. So if clang in Windows also defines the _MSC_EXTENSIONS macro it should ideally emulate MSVC in that regard.<br>
</blockquote><div><br></div><div>I agree, this is a reasonable expectation, but I would classify this bug as low priority, since variadic fastcall doesn't make sense.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

I will however mention in the Boost developers forum that it might be good to drop the overloaded vararg specializations with non-standard calling conventions for MSVC. Or Boost could decide to test for clang and not allow it when using clang.</blockquote>
<div><br></div><div>Boost probably should drop this specialization.  It's actually declaring the __cdecl specialization after the implicit adjustment.  When I attempt to define a specialization for both 'R (__fastcall *)(...)' and 'R (__cdecl *)(...)' in the same TU, I get a compiler error from MSVC:</div>
<div><div>t.cpp(7) : error C2995: 'void is_function_template(R (__cdecl *)(...))' : function template has already been defined</div><div>        t.cpp(5) : see declaration of 'is_function_template'</div></div>
<div><br></div><div><div>extern "C" int printf(const char *fmt, ...);</div><div>template <typename T></div><div>void is_function_template(T t) { printf("no\n"); }</div><div>template <typename R></div>
<div>void is_function_template(R (__cdecl *fptr)(...)) { printf("cdecl\n"); }</div><div>template <typename R></div><div>void is_function_template(R (__fastcall *fptr)(...)) { printf("fastcall\n"); }</div>
</div><div><br></div></div></div></div>