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

[MIR] Calling extern functions. #30517

Closed
wants to merge 1 commit into from

Conversation

luqmana
Copy link
Member

@luqmana luqmana commented Dec 22, 2015

Definitely conflicts with #30481 (sorry @nagisa) but wanted to get some eyes on this.

@rust-highfive
Copy link
Collaborator

r? @pnkfelix

(rust_highfive has picked a reviewer for you, use r? to override)

@@ -88,6 +88,19 @@ fn test8() -> isize {
Two::two()
}

#[link(name = "c")]
extern {
fn printf(format: *const u8, ...) -> i32;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

hmm, is there something other than printf that we could test here?

I mean, I guess its fine (if a little opaque) to rely on the return value of printf as the basis for the test; but then again, that's relying on them never returning an error code ... seems like there are more direct options here, like strlen, or qsort, (well qsort might be a bit of a stretch).

If you are deliberately trying to test the handling of varargs functions, then maybe go with sscanf? Basically I'm trying to avoid doing IO where the output isn't actually checked for correctness, since that might mask bugs...

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Probably the most obvious VA_ARG function to test is syscall, but it is system-dependent (duh).

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Other functions are fcntl, ioctl, execl{,e,p}. Exec might be a good one I think.

@pnkfelix
Copy link
Member

pnkfelix commented Jan 5, 2016

@luqmana sorry it took me so long to get to this

r=me if the test is revised or if someone puts up a convincing argument that it isn't worth revising. :)

@nagisa
Copy link
Member

nagisa commented Jan 5, 2016

Note, #30481 is already in queue and this gonna need significant changes to get rebased.

@bors
Copy link
Contributor

bors commented Jan 6, 2016

☔ The latest upstream changes (presumably #30692) made this pull request unmergeable. Please resolve the merge conflicts.

@luqmana
Copy link
Member Author

luqmana commented Jan 12, 2016

Closed in favour of #30845.

@luqmana luqmana closed this Jan 12, 2016
bors added a commit that referenced this pull request Jan 14, 2016
bors added a commit that referenced this pull request Jan 19, 2016
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

Successfully merging this pull request may close these issues.

5 participants