cdecl

[Fraser 2]

I am not sure what is happening when I export functions with __cdecl.  When I build with 32-bit clang there is one prefixed underscore on all function names.  When I build with 64-bit clang there is no prefixed underscore on function names.  The documentation says this about cdecl: "Note: This feature is available only for the classic bcc32 compiler, not for the modern Clang-enhanced compiler."  It also says:"Note: The __cdecl form is the only one supported by C++Builder 64-bit Windows (BCC64)."  Is this not a contradiction?

 

The compiler option "Generate underscores on symbol names" made no difference to my 32-bit builds.  I have not found any way of using cdecl with 32-bit builds and to not get leading underscores which means I cannot build zlib1.dll which specifies no underscores.

[Remy Lebeau 1398]

3 hours ago, Fraser said:

When I build with 32-bit clang there is one prefixed underscore on all function names.

That is normal behavior.

Quote

When I build with 64-bit clang there is no prefixed underscore on function names.

That is also normal behavior.

Quote

The documentation says this about cdecl: "Note: This feature is available only for the classic bcc32 compiler, not for the modern Clang-enhanced compiler."  It also says:"Note: The __cdecl form is the only one supported by C++Builder 64-bit Windows (BCC64)."  Is this not a contradiction?

Calling conventions like cdecl and stdcall simply don't exist in 64bit, and they are ignored completely when used in code.  There is only 1 standardized 64bit calling convention, and its behaviors are dictated by the 64bit ABI.  And the 64bit calling convention indeed does not use the same name mangling rules that the 32bit cdecl calling convention uses.

Quote

I have not found any way of using cdecl with 32-bit builds and to not get leading underscores

Use a .DEF file to control how the linker (or IMPLIB tool) formats exported names, and what internal names those exported names map to.

Edited August 10, 2022 by Remy Lebeau

[Fraser 2]

I had discovered some of this.  The documentation needs some correcting.