Skip to content

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

New issue

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

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

Already on GitHub? # to your account

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.
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants