cc @brson/@thestinger

• 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.

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

cc #12514 and #2124

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

Or "libclib"?

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

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).

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

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

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.)

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
.

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

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

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?

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

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

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.

So r?

@cmr looks like this needs to be rebased.

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
.

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
.

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

@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
.

@Jurily: libstd can depend on libc

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.

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
.

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.

@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).

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

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

Closing in favor of #13315