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

Avoid emitting extern "C" for private functions #1153

Open
bjorn3 opened this issue Oct 30, 2024 · 1 comment
Open

Avoid emitting extern "C" for private functions #1153

bjorn3 opened this issue Oct 30, 2024 · 1 comment
Labels
enhancement New feature or request

Comments

@bjorn3
Copy link

bjorn3 commented Oct 30, 2024

There is no need to remain ABI compatible with C for them as they can't be called from C anyway (except for when it is turned into a function pointer, then extern "C" needs to remain), yet does increase the amount of work necessary to clean up the output generated by c2rust.

@kkysen kkysen added the enhancement New feature or request label Oct 31, 2024
@kkysen
Copy link
Contributor

kkysen commented Oct 31, 2024

This is a good simple thing we should improve for non-address taken static in C/private in Rust fns. On the other hand, it is luckily not too hard to do for the majority of cases with a manual 3-step find and replace:

  1. pub unsafe extern "C" fn => something
  2. unsafe extern "C" fn => unsafe fn
  3. something => pub unsafe extern "C" fn

Also, in my personal experience cleaning up and safetifying c2rust transpiled code, there was so much code to clean up in each function besides even safety that I used the existence of extern "C" as a marker for if I had cleaned up that function yet, rather than doing them wholesale at once.

Obviously, we'd much rather work on making the output much more manageable even before making it safe, and we hope to work more on such efforts when we have time to do so.

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

No branches or pull requests

2 participants