"a calling convention may not be followed by a nested declarator"

"a calling convention may not be followed by a nested declarator"

I'm trying to specify a Windows 32 calling convention on a function whose name is a macro, similar to the following:

#define AddPrefix(x) (prefix##x)
#define function AddPrefix(function)
void __cdecl function( void );

int main( int argc, char **argv )
{
    return 0;
}

But the compiler raises the following error:

Intel(R) C++ Compiler XE for applications running on IA-32, Version 13.0.0.089 Build 20120731
Copyright (C) 1985-2012 Intel Corporation.  All rights reserved.

test.c
test.c(4): error: a calling convention may not be followed by a nested declarator
  void __cdecl function( void );
         ^

compilation aborted for test.c (code 2)

Is there anyway to specify a calling convention on declarations like this?  I need to include a header file with declarations as in my example above into a C file built with -Gz, which causes __stdcall to be the default.  Of course the shared library that matches the header was built without -Gz, so its exports are __cdecl.

10 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

the problem is the parenthesis around the function name, can you change the AddPrefix macro to:

#define AddPrefix(x) prefix##x

Judy

 

Ok, I can work with that.

Thanks

Darin

Judith, Thanks for the workaround. However,

>>#define AddPrefix(x) ( prefix##x )
>>...

I did a verification with a legacy C++ compiler Borland C++ version 5.5.1:

..\Test>bcc32.exe Main.cpp
Borland C++ 5.5.1 for Win32 Copyright (c) 1993, 2000 Borland
Main.cpp:
Turbo Incremental Link 5.00 Copyright (c) 1997, 2000 Borland
Main.cpp - 0 error(s), 0 warning(s)

and it did Not have Any compilation errors with the test case provided. So, I consider it as a bug with Intel C++ compiler ( Also reproduced with a version 12.1.7.371 Build 20120928 ).

 

This is not a bug. On Windows we emulate the Microsoft compiler and they give an error too.

Judy

[SergeyK] ...I consider it as a bug with Intel C++ compiler...
...
[JudithW] ...This is not a bug...

Judith,

You're Not arguing with me. You're arguing with Borland. That is, with a leading ( in the past ) developer of high-performance ( very robust! ) C/C++ compilers. I use Borland C++ compiler for additional verifications that fundamental standards / specifications are properly supported and implemented. However, I'll do additional verification with MS Visual C++ v4.2 ( ~1995 year technology ) and let you know results.

Judith, I did a quick verification with a Microsoft C++ compiler and I reproduced the compilation error:

[ Microsoft C++ compiler version 14 - FAILED ]
...
..\Test>cl.exe Main.cpp
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 14.00.50727.762 for 80x86
Copyright (C) Microsoft Corporation. All rights reserved.

Main.cpp
Main.cpp(4) : error C2059: syntax error : '('
...

Here is another verification with a legacy C++ compiler Turbo C++:

[ Turbo C++ compiler version 3 - SUCCESS ]
...
..\Test>tcc Main.cpp
Turbo C++ Version 3.00 Copyright (c) 1992 Borland International
main.cpp:
Warning main.cpp 9: Parameter 'argc' is never used in function main(int,char * *)
Warning main.cpp 9: Parameter 'argv' is never used in function main(int,char * *)
Turbo Link Version 5.0 Copyright (c) 1992 Borland International
Available memory 4124672
...

I see that Intel and Microsoft C++ compilers have bugs and I agree that as a workaround brackets need to be removed in the #define statement with ##.

 

Calling conventions are not part of the C or C++ standard. They are a Microsoft extension and thus Microsoft implemented the "de facto" standard.

 

>>...Calling conventions are not part of the C or C++ standard...

I'm not talking about _cdecl declaration. Extra brackets used around ( prefix##x ) create the Incompatibility problem with all the rest existing C++ compilers.

Here are results of additional verification:

Intel C++ v13.x - Failed ( VS 2008 )
Intel C++ v12.x - Failed ( VS 2005 )
Intel C++ v8.x - Failed ( VS 98 )

Microsoft C++ v17.x - Failed ( VS 2012 )
Microsoft C++ v16.x - Failed ( VS 2010 )
Microsoft C++ v15.x - Failed ( VS 2008 )
Microsoft C++ v14.x - Failed ( VS 2005 )
Microsoft C++ v12.x - Failed ( VS 98 )

MinGW v3.4.2 - Success ( integrated with VS 2005 )

Borland C++ v5.x - Success ( integrated with VS 2005 )
Turbo C++ v3.x - Failed ( integrated with VS 2005 )
Turbo C++ v1.x - Failed

Also, Intel C++ compiler option /Qms0 ( disable Microsoft compatibility bugs ) doesn't make any difference.

Leave a Comment

Please sign in to add a comment. Not a member? Join today