Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support calling convention specification #718

Open
mattiekat opened this issue Oct 12, 2021 · 3 comments
Open

Support calling convention specification #718

mattiekat opened this issue Oct 12, 2021 · 3 comments

Comments

@mattiekat
Copy link

mattiekat commented Oct 12, 2021

I am a native rust coder so take this with a grain of salt:

My understanding is that when you are creating a library it is best practice to define the calling convention because someone may be using a different default and then when they try to link with your code it will fail without first re-writing your header.

It should be possible to just add __cdecl if it is extern "C" or __stdcall if it is extern "stdcall" and so on.

Specifically the request here is to allow explicitly saying __cdecl on functions, since right now function prefix/postfix settings won't allow putting this into the declarations.

@mattiekat mattiekat changed the title Support calling convention definitions Support calling convention specification Oct 12, 2021
@mattiekat
Copy link
Author

Relates to #55

@lzybkr
Copy link

lzybkr commented May 2, 2022

It would be useful to always specify the calling convention.

I came across this issue because I hit linker errors with unresolved externals because somebody was passing the /Gz flag to VC++. This option says "make all unannotated functions stdcall" and my Rust functions were compiled with the default (cdecl).

For now I think my only option is to edit the cbindgen generated header because I can't know which compiler flags will be used.

@emilio
Copy link
Collaborator

emilio commented Jun 6, 2022

@lzybkr Feel free to send a patch with an option to specify the concrete calling convention, that seems like a reasonable use-case.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants