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

pub extern functions aren't considered unsafe from other crates #5844

Closed
doy opened this issue Apr 11, 2013 · 3 comments
Closed

pub extern functions aren't considered unsafe from other crates #5844

doy opened this issue Apr 11, 2013 · 3 comments

Comments

@doy
Copy link
Contributor

doy commented Apr 11, 2013

// crate.rs
#[crate_type = "lib"];

pub extern "C" {
    fn rand() -> libc::c_int;
}
// test.rs
extern mod crate;

fn main () {
    println(fmt!("%?", crate::rand()));
}

Compiling these as separate crates doesn't produce an error, but compiling them both as part of the same crate does, as does compiling a crate which uses a function from a different crate which was explicitly marked as unsafe. It seems like this should be consistent.

@ILyoan
Copy link
Contributor

ILyoan commented May 27, 2013

Still relevant. and I think this should require unsafe block.
Nominating for milestone 1 (well-defined)

@jdm
Copy link
Contributor

jdm commented May 27, 2013

Nominating for milestone 1 (well-defined)

@bstrie
Copy link
Contributor

bstrie commented May 31, 2013

It appears that this was accepted for Maturity 1, well-defined.

alexcrichton added a commit to alexcrichton/rust that referenced this issue Jul 23, 2013
@bors bors closed this as completed in b5799e1 Jul 24, 2013
flip1995 pushed a commit to flip1995/rust that referenced this issue May 20, 2021
…ednet

`while_let_on_iterator` Improvements

fixes: rust-lang#6491
fixes: rust-lang#6231
fixes: rust-lang#5844
fixes: rust-lang#1924
fixes: rust-lang#1033

The check for whether a field can be borrowed should probably be moved to utils at some point, but it would require some cleanup work and knowing what parts can actually be shared.

changelog: Suggest `&mut iter` when the iterator is used after the loop.
changelog: Suggest `&mut iter` when the iterator is a field in a struct.
changelog: Don't lint when the iterator is a field in a struct, and the struct is used in the loop.
changelog: Lint when the loop is nested in another loop, but suggest `&mut iter` unless the iterator is from a local declared inside the loop.
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 a pull request may close this issue.

4 participants