(adding back cfe-commits, which I had accidentally dropped.) On Thu, Jul 31, 2014 at 1:04 PM, Reid Kleckner <[email protected]> wrote:
> On Thu, Jul 31, 2014 at 11:16 AM, Nico Weber <[email protected]> wrote: > >> On Thu, Jul 31, 2014 at 9:45 AM, Nico Weber <[email protected]> wrote: >> >>> Thanks! >>> >>> On Tue, Jul 29, 2014 at 10:40 AM, Reid Kleckner <[email protected]> wrote: >>> >>>> + // Diagnose the use of X86 fastcall on unprototyped functions. >>>> >>>> We should also diagnose unprototyped stdcall functions, but I'm not >>>> sure if that would be too disruptive. Currently we accept this and always >>>> call _f@0: >>>> void __stdcall f(); >>>> int main() { >>>> f(1); >>>> f(1, 2); >>>> f(1, 2, 3); >>>> } >>>> >>>> MSVC rejects with "t.c(5) : error C2708: 'f' : actual parameters length >>>> in bytes differs from previous call or reference". >>>> >>> >>> I added a TODO for adding this and reshuffled the if to make this easy >>> to add. I'll give it a try once this patch is in. >>> >> >> > Actually, should this happen for all isCalleeCleanup() calling >> conventions? I suppose thiscall always has a prototype, but pascal(l :-P) >> might not? >> > > That sounds like the right predicate, considering we verifier-fail on this > in plain C mode: > void __thiscall f(); > int main() { f(1); } > > MSVC rejects __thiscall in C mode, but we don't. > I did give it a try, and rejecting stdcall fires on Windows SDK headers: ...win8sdk/Include/um\imm.h(432,13) : error(clang): function with no prototype cannot use stdcall calling convention BOOL WINAPI ImmDisableLegacyIME(); ^ So the same mechanism doesn't work for stdcall. We could do the same thing for thiscall, but if msvc rejects that in C files, we should probably just do that too?
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
