Skip to content

Conversation

@Ericson2314
Copy link
Contributor

libc is only used when the heap allocations are not defined externally, or defined in another crate. I assume these extern* configurations were added for the sake of those of us experimenting with freestanding Rust. Avoiding libc where possible is often very important for us.

@rust-highfive
Copy link
Contributor

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @nikomatsakis (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. The way Github handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

Please see CONTRIBUTING.md for more information.

@Ericson2314
Copy link
Contributor Author

This should be g2g. The second commit was needed because the 100 char lint. The third fixes preexisting bugs.

@emberian
Copy link
Contributor

emberian commented Jan 3, 2015

Looks good to me, #rust-osdev has been clamoring for this. @aturon / @alexcrichton what do you think about the use of feature here? AIUI the #rust-osdev people have pulled this out into a cargoified crate.

@Ericson2314
Copy link
Contributor Author

Yup, I am building core through collections, and an allocator in a separate crate, all with cargo and everything is working great! I see that "feature" isn't the ideal word for this, but seeing that's what cargo offers I can only hope a stray feature behind the facade is better than one on it.

@alexcrichton
Copy link
Member

Huh, I thought I saw this get approved awhile ago. Sorry this has been sitting for awhile @Ericson2314!

I'm not sure that we'll want to commit long-term to a strategy like this, but I'm pretty ok with this for now as it's basically just an experimental crate. So long as it builds for master continuously, we should be good!

@Ericson2314
Copy link
Contributor Author

No worries at all, cmr did r+ it, but then i pushed more commits. Yeah long term the allocator API will render messing with liballoc unnecessary I assume. Thank you both!

bors added a commit that referenced this pull request Jan 3, 2015
…crichton

libc is only used when the heap allocations are not defined externally, or defined in another crate. I assume these extern* configurations were added for the sake of those of us experimenting with freestanding Rust. Avoiding libc where possible is often very important for us.
alexcrichton added a commit to alexcrichton/rust that referenced this pull request Jan 8, 2015
libc is only used when the heap allocations are not defined externally, or defined in another crate. I assume these extern* configurations were added for the sake of those of us experimenting with freestanding Rust. Avoiding libc where possible is often very important for us.
@bors bors merged commit b1b4bc9 into rust-lang:master Jan 8, 2015
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.

7 participants