Remove libc from std #12526

emberian · 2014-02-24T20:47:12Z

Remove libc from std

alexcrichton · 2014-02-24T20:51:45Z

liblibc :)
Could extern crate c; work? Our naming scheme means that we'd never collide with a system libc.
std depending on libc (which kinda makes sense) means that we probably couldn't move c_vec or c_str into this module (which seem desirable?)
#[no_std] seems correct to me.

brson · 2014-02-24T20:59:35Z

c_vec at least has very few dependencies. c_str is much harder. c_str on the other hand has very few dependencies on libc

huonw · 2014-02-24T20:59:56Z

cc #12514 and #2124

brson · 2014-02-24T21:01:00Z

Regardless of the ultimate fate of libc bindings this is a good first step. The big question to me is "liblibc or libc?".

brson · 2014-02-24T21:01:13Z

Or "libclib"?

brson · 2014-02-24T21:02:04Z

It would be nice if std somebody does not depend on libc (or maybe just ctypes).

alexcrichton · 2014-02-24T21:04:44Z

Ah another thing that I was just reminded of is that it's likely for many crates to depend on C types, but not necessarily on the C functions. Just a thought though.

I think that moving c_vec and c_str into this crate will require a libprim in one form or another. (both need the Drop trait for example).

liigo · 2014-02-25T00:03:27Z

"liblibc"?? A little weird. Why not just "libc"? I really think c::int is better than libc::c_int.

emberian · 2014-02-25T00:09:16Z

I don't think c_* moving here is a good idea. This is bindings to the C standard library, not utilities for interfacing with C in general. Those could probably usefully live in a std::ffi

huonw · 2014-02-25T00:19:14Z

I really think c::int is better than libc::c_int.

I think there's a bug in resolve that types with the same name as primitives aren't resolved correctly, so this would restrict it to always being used as c::int, possibly resulting in weird FFI bugs. (I can't find the bug filed about the resolution bug now.)

emberian · 2014-02-25T00:22:03Z

Additionally, they're always imported as "c_int" etc, so the name is
actually getting longer and harder to read IMO.

On Mon, Feb 24, 2014 at 7:19 PM, Huon Wilson notifications@github.comwrote:

I really think c::int is better than libc::c_int.

I think there's a bug in resolve that types with the same name as
primitives aren't resolved correctly, so this would restrict it to
always being used as c::int, possibly resulting in weird FFI bugs. (I
can't find the bug filed about the resolution bug now.)

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/12526#issuecomment-35960256
.

brson · 2014-02-25T00:23:40Z

It would be nice if "someday" std doesn't depend on libc.

emberian · 2014-02-25T00:25:51Z

Do we want to name it c? I can try and fix the resolve bug (which I just confirmed) if so.

bharrisau · 2014-02-25T00:27:38Z

If rt has all the "talk to the OS" stuff, and libc/ffi has all the "talk to
external C code", would that count as std not depending on libc?

emberian · 2014-02-25T00:28:37Z

rt is in std, but there's also a std::os, and std::io uses a lot of libc. at least the types.

liigo · 2014-02-25T10:16:48Z

c::int VS. libc::c_int
To import: don't need VS. use libc::{c_int}
To use: let x: c::int VS. let x: c_int
To read: the same, read as c int
c::int is a bit more cleaner.
@cmr @huonw @brson

huonw · 2014-02-25T11:19:05Z

Having two types called int that behave differently is a no-go for me; the bugs it will cause will be very annoying to track down. Examples just off the top of my head

extern {
    fn foo(x: int); // whoops, meant to be c::int, subtly incorrect on x86-64
}

use c::int;
extern {
    // ... use `int` a lot ...
}

fn x() -> uint { computation() }

fn y() {
    let i = x() as int; // whoops, meant to be built-in `int`, lost precision on x86-64
    // ...
}

One might say "no-one will ever import c::int to be just int", but if it's legal Rust then it will end up in codebases.

Basically, it would make FFI a bigger mine-field than it already is: it's confusing enough that Rust's int isn't the same as C's int: having two Rust ints which sometime match C and sometimes don't would be horrible.

emberian · 2014-02-25T14:06:25Z

So r?

flaper87 · 2014-02-25T14:12:58Z

@cmr looks like this needs to be rebased.

emberian · 2014-02-25T14:32:12Z

updated

On Tue, Feb 25, 2014 at 9:13 AM, Flavio Percoco Premoli <
notifications@github.com> wrote:

@cmr https://github.com/cmr looks like this needs to be rebased.

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/12526#issuecomment-36010552
.

liigo · 2014-02-25T15:35:18Z

Please keep in mind, we do have namespaces, c::int is not the same as
int.
2014年2月25日下午7:19于 "Huon Wilson" notifications@github.com写道：

Having two types called int that behave differently is a no-go; the bugs
it will cause will be very annoying to track down. Examples just off the
top of my head

extern {
fn foo(x: int); // whoops, meant to be c::int, subtly incorrect on x86-64}

use c::int;extern {
// ... use int a lot ...}
fn x() -> uint { computation() }
fn y() {
let i = x() as int; // whoops, meant to be built-in int, lost precision on x86-64
// ...}

One might say "no-one will ever import c::int to be just int", but if
it's legal Rust then it will end up in codebases.

Basically, it would make FFI a bigger mine-field than it already is: it's
confusing enough that Rust's int isn't the same as C's int: having two
Rust ints which sometime match C and sometimes don't would be horrible.

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/12526#issuecomment-35997743
.

ghost · 2014-02-25T15:51:52Z

We should keep c_int and friends in std. We'll need them without libc too.

emberian · 2014-02-25T15:53:51Z

@liigo not when you use it, and libc itself won't be able to use those
due to a bug. There's traction for making the built-in types keywords, too,
so that would make it a moot point.

On Tue, Feb 25, 2014 at 10:51 AM, György Andrasek
notifications@github.comwrote:

We should keep c_int and friends in std. We'll need them without libc too.

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/12526#issuecomment-36021945
.

thestinger · 2014-02-25T16:33:55Z

@Jurily: libstd can depend on libc

ghost · 2014-02-25T20:39:41Z

The basic C types are not defined by libc. We need them to do any sort of FFI including kernel modules and writing libc itself. They're just typedefs over Rust builtins anyway, I don't see a good reason to move them out of std.

emberian · 2014-02-25T22:22:45Z

I'm comfortable moving them out of libstd, until we have
libclang-integrated FFI to get the actual sizes for the platform ABI.

On Tue, Feb 25, 2014 at 3:39 PM, György Andrasek
notifications@github.comwrote:

The basic C types are not defined by libc. We need them to do any sort of
FFI including kernel modules and writing libc itself. They're just
typedefs over Rust builtins anyway, I don't see a good reason to move them
out of std.

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/12526#issuecomment-36055234
.

alexcrichton · 2014-02-26T02:10:11Z

It sounds like everyone is in mostly favor of moving libc out of libstd. There's still a lot of decisions to make about things like whether the types are separate from the functions and such, but I believe that this is a good step forward.

I would like to make progress on this extraction. I'd like to take one last look, but other than that r+ with a rebase.

huonw · 2014-02-26T02:53:34Z

@liigo, also, I forgot to say, but

To import: don't need VS. use libc::{c_int}

isn't true. In anything but the crate root, use c; is required to bring c::int into scope (or else it's required to write ::c::int instead).

liigo · 2014-02-26T04:01:35Z

Oh yes, now i know why c_int can't be renamed to c::int. Thank you @cmr @huonw !

alexcrichton · 2014-03-02T22:45:20Z

r=me with an update to src/doc/index.md (sorry I forgot that earlier)

These wrappers are bound to a specific libc, and they don't need to be part of libstd.

libc: remove stray impl in win32

alexcrichton · 2014-04-04T21:02:16Z

Closing in favor of #13315

Rebasing of #12526 with a very obscure bug fixed on windows.

Mention `size_hint()` effect in `flat_map_option` lint documentation. The previous documentation for `flat_map_option` mentioned only readability benefits, but there is also at least one performance benefit: the `size_hint()` upper bound is preserved, whereas `flat_map().size_hint()` is always `(0, None)`. Program demonstrating this difference: ```rust fn main() { let evens = |i| if i % 2 == 0 { Some(i) } else { None }; dbg!( [1, 2, 3].iter().flat_map(evens).size_hint(), [1, 2, 3].iter().filter_map(evens).size_hint(), ); } ``` changelog: [`flat_map_option`]: Mention the benefit to `size_hint()`.

emberian added 10 commits March 28, 2014 01:02

Remove libc from std

8ddd5f5

These wrappers are bound to a specific libc, and they don't need to be part of libstd.

fix fallout from std::libc separation

301dd7a

Add unrecognized_lint

c258f5c

fix more fallout

dad9656

libc: remove stray impl in win32

rand: fix libc fallout

c6fb8c1

libc: make windows happy

ca406fa

Change how the readdir/opendir hack works

8959ade

ever more fallout

9706372

libc: link to libc and libm

9ed82c7

switch to native for start lang item

f64fdf5

alexcrichton mentioned this pull request Apr 4, 2014

Extract std::libc to its own crate #13315

Merged

alexcrichton closed this Apr 4, 2014

bors added a commit that referenced this pull request Apr 6, 2014

auto merge of #13315 : alexcrichton/rust/libc, r=alexcrichton,me

f1f5056

Rebasing of #12526 with a very obscure bug fixed on windows.

kennytm mentioned this pull request Mar 14, 2018

[libstd] fix typo in docs #49021

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Remove libc from std #12526

Remove libc from std #12526

emberian commented Feb 24, 2014

alexcrichton commented Feb 24, 2014

brson commented Feb 24, 2014

huonw commented Feb 24, 2014

brson commented Feb 24, 2014

brson commented Feb 24, 2014

brson commented Feb 24, 2014

alexcrichton commented Feb 24, 2014

liigo commented Feb 25, 2014

emberian commented Feb 25, 2014

huonw commented Feb 25, 2014

emberian commented Feb 25, 2014

brson commented Feb 25, 2014

emberian commented Feb 25, 2014

bharrisau commented Feb 25, 2014

emberian commented Feb 25, 2014

liigo commented Feb 25, 2014

huonw commented Feb 25, 2014

emberian commented Feb 25, 2014

flaper87 commented Feb 25, 2014

emberian commented Feb 25, 2014

liigo commented Feb 25, 2014

ghost commented Feb 25, 2014

emberian commented Feb 25, 2014

thestinger commented Feb 25, 2014

ghost commented Feb 25, 2014

emberian commented Feb 25, 2014

alexcrichton commented Feb 26, 2014

huonw commented Feb 26, 2014

liigo commented Feb 26, 2014

alexcrichton commented Mar 2, 2014

alexcrichton commented Apr 4, 2014

Remove libc from std #12526

Remove libc from std #12526

Conversation

emberian commented Feb 24, 2014

alexcrichton commented Feb 24, 2014

brson commented Feb 24, 2014

huonw commented Feb 24, 2014

brson commented Feb 24, 2014

brson commented Feb 24, 2014

brson commented Feb 24, 2014

alexcrichton commented Feb 24, 2014

liigo commented Feb 25, 2014

emberian commented Feb 25, 2014

huonw commented Feb 25, 2014

emberian commented Feb 25, 2014

brson commented Feb 25, 2014

emberian commented Feb 25, 2014

bharrisau commented Feb 25, 2014

emberian commented Feb 25, 2014

liigo commented Feb 25, 2014

huonw commented Feb 25, 2014

emberian commented Feb 25, 2014

flaper87 commented Feb 25, 2014

emberian commented Feb 25, 2014

liigo commented Feb 25, 2014

ghost commented Feb 25, 2014

emberian commented Feb 25, 2014

thestinger commented Feb 25, 2014

ghost commented Feb 25, 2014

emberian commented Feb 25, 2014

alexcrichton commented Feb 26, 2014

huonw commented Feb 26, 2014

liigo commented Feb 26, 2014

alexcrichton commented Mar 2, 2014

alexcrichton commented Apr 4, 2014