Skip to content

fns using c-stack-cdecl native ABI cannot be called from outside crate #1059

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

Closed
nikomatsakis opened this issue Oct 21, 2011 · 7 comments
Closed

Comments

@nikomatsakis
Copy link
Contributor

Calling a native function declared with "c-stack-cdecl" ABI from outside the create fails in LLVM. The type of the function includes the implicit parameters when it should not. The path through the code is: The code path is that when we look up the external identifier we go through trans_external_path() -> type_of_ty_param_kinds_and_ty() -> type_of_fn_from_ty() -> type_of_fn(), and type_of_fn() adds the implicit parameters.

I added a test: src/test/run-pass/invoke-external-native.rs

@brson
Copy link
Contributor

brson commented Nov 8, 2011

I don't see how this works for "cdecl" functions.

@brson
Copy link
Contributor

brson commented Nov 8, 2011

Maybe cdecl functions have a wrapper...

@nikomatsakis
Copy link
Contributor Author

First question: do cdecl functions work? I would be happy to investigate this further, should be easy to port the test over to cdecl.

@brson
Copy link
Contributor

brson commented Nov 8, 2011

Yeah, native "cdecl" functions do work across crates. Some of the stdtest::run tests rely on this. I'm thinking of just working around the problem in order to eliminate the last usages of "cdecl".

@nikomatsakis
Copy link
Contributor Author

Oh, ok. Yeah, that's annoying. I didn't trace the path through the code that cdecl functions take, clearly something different though.

On Nov 7, 2011, at 7:45 PM, Brian Anderson wrote:

Yeah, native "cdecl" functions do work across crates. Some of the stdtest::run tests rely on this. I'm thinking of just working around the problem in order to eliminate the last usages of "cdecl".


Reply to this email directly or view it on GitHub:
https://github.com/graydon/rust/issues/1059#issuecomment-2663511

@nikomatsakis
Copy link
Contributor Author

After some review, I think the way that it worked was that "cdecl" natives got wrapped in a rust wrapper. I plan to re-implement this at some point, it seems that it solves a myriad of issues (#1058, #1174, at least).

nikomatsakis added a commit to nikomatsakis/rust that referenced this issue Nov 19, 2011
nikomatsakis added a commit to nikomatsakis/rust that referenced this issue Nov 19, 2011
@nikomatsakis
Copy link
Contributor Author

Fixed in @b6af844

coastalwhite pushed a commit to coastalwhite/rust that referenced this issue Aug 5, 2023
celinval added a commit to celinval/rust-dev that referenced this issue Jun 4, 2024
* Add --enable-unstable option

Unstable options now require users to explicitly enable them. This is
important because the unstable options can be unsound or give spurious
CEX.

* Disable spurious pointer checks by default

We have been seeing a lot of spurious CEX related to pointer out of
bounds checks in arithmetic operations. It is actually valid rust in
some cases, and we can't differentiate the valid ones from the invalid
ones today. Thus, I'm disabling them by default.

Note that dereferencing invalid pointers is caught by different checks
and they should not be affected by this change.

This changes fixes rust-lang#563 and rust-lang#763.

Co-authored-by: Zyad Hassan <[email protected]>
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

2 participants