Repository files navigation

A Rust library with native bindings to the types and functions commonly found onvarious systems, including libc.

First, add the following to yourCargo.toml:

[dependencies]libc ="0.2"

Next, add this to your crate root:

externcrate libc;

Currently libc by default links to the standard library, but if you wouldinstead like to use libc in a#![no_std] situation or crate you can requestthis via:

[dependencies]libc = {version ="0.2",default-features =false }

By default libc uses private fields in structs in order to enforce a certainmemory alignment on them. These structs can be hard to instantiate outside oflibc. To make libc use#[repr(align(x))], instead of the private fields,activate thealign feature. This requires Rust 1.25 or newer:

[dependencies]libc = {version ="0.2",features = ["align"] }

The primary purpose of this crate is to provide all of the definitions necessaryto easily interoperate with C code (or "C-like" code) on each of the platformsthat Rust supports. This includes type definitions (e.g.c_int), constants(e.g.EINVAL) as well as function headers (e.g.malloc).

This crate does not strive to have any form of compatibility across platforms,but rather it is simply a straight binding to the system libraries on theplatform in question.

This crate exports all underlying platform types, functions, and constants underthe crate root, so all items are accessible aslibc::foo. The types and valuesof all the exported APIs match the platform that libc is compiled for.

More detailed information about the design of this library can be found in itsassociated RFC.

Want to use an API which currently isn't bound inlibc? It's quite easy to addone!

The internal structure of this crate is designed to minimize the number of#[cfg] attributes in order to easily be able to add new items which applyto all platforms in the future. As a result, the crate is organizedhierarchically based on platform. Each module has a number of#[cfg]'dchildren, but only one is ever actually compiled. Each module then reexports allthe contents of its children.

This means that for each platform that libc supports, the path from aleaf module to the root will contain all bindings for the platform in question.Consequently, this indicates where an API should be added! Adding an API at aparticular level in the hierarchy means that it is supported on all the childplatforms of that level. For example, when adding a Unix API it should be addedtosrc/unix/mod.rs, but when adding a Linux-only API it should be added tosrc/unix/notbsd/linux/mod.rs.

If you're not 100% sure at what level of the hierarchy an API should be addedat, fear not! This crate has CI support which tests any binding against allplatforms supported, so you'll see failures if an API is added at the wronglevel or has different signatures across platforms.

With that in mind, the steps for adding a new API are:

1. Determine where in the module hierarchy your API should be added.
2. Add the API.
3. Send a PR to this repo.
4. Wait for CI to pass, fixing errors.
5. Wait for a merge!

We have two automated tests running onTravis:

1. libc-test

• cd libc-test && cargo test
• Use theskip_*() functions inbuild.rs if you really need a workaround.

2. Style checker

• rustc ci/style.rs && ./style src

Now that you've done the amazing job of landing your new API or your newplatform in this crate, the next step is to get that sweet, sweet usage fromcrates.io! The only next step is to bump the version of libc and then publishit. If you'd like to get a release out ASAP you can follow these steps:

1. Update the version number inCargo.toml, you'll just be bumping the patchversion number.
2. Runcargo update to regenerate the lockfile to encode your version bump inthe lock file. You may pull in some other updated dependencies, that's ok.
3. Send a PR to this repository. It shouldlook like this, but it'dalso be nice to fill out the description with a small rationale for therelease (any rationale is ok though!)
4. Once merged the release will be tagged and published by one of the libc cratemaintainers.

The following platforms are currently tested and have documentation available:

Tested:

• i686-pc-windows-msvc
• x86_64-pc-windows-msvc(Windows)
• i686-pc-windows-gnu
• x86_64-pc-windows-gnu
• i686-apple-darwin
• x86_64-apple-darwin(OSX)
• i386-apple-ios
• x86_64-apple-ios
• i686-unknown-linux-gnu
• x86_64-unknown-linux-gnu(Linux)
• x86_64-unknown-linux-musl(Linux MUSL)
• aarch64-unknown-linux-gnu(Linux)
• aarch64-unknown-linux-musl(Linux MUSL)
• sparc64-unknown-linux-gnu(Linux)
• mips-unknown-linux-gnu
• arm-unknown-linux-gnueabihf
• arm-linux-androideabi(Android)
• x86_64-unknown-freebsd
• x86_64-unknown-openbsd
• x86_64-rumprun-netbsd

The following may be supported, but are not guaranteed to always work:

• i686-unknown-freebsd
• x86_64-unknown-bitrig
• x86_64-unknown-dragonfly
• i686-unknown-haiku
• x86_64-unknown-haiku
• x86_64-unknown-netbsd
• x86_64-sun-solaris