author Bastien Orivel <>
Wed, 22 Aug 2018 20:19:04 +0200
changeset 488156 03df1a267ea54f1024d3f015f4bf781477262c92
parent 440339 11534e7b5e275744ee6951f696146a0099a58b18
child 526922 40052223c3a219aeaccb3ff9f0a556ba781f9a68
permissions -rw-r--r--
Bug 1484462 - Revendor Rust dependencies. r=ato


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

[![Build Status](](
[![Build status](](
[![Latest version](](

## Usage

First, add the following to your `Cargo.toml`:

libc = "0.2"

Next, add this to your crate root:

extern crate libc;

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

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

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

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

## What is libc?

The primary purpose of this crate is to provide all of the definitions necessary
to easily interoperate with C code (or "C-like" code) on each of the platforms
that 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 the
platform in question.

## Public API

This crate exports all underlying platform types, functions, and constants under
the crate root, so all items are accessible as `libc::foo`. The types and values
of 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 its
[associated RFC][rfc].


## Adding an API

Want to use an API which currently isn't bound in `libc`? It's quite easy to add

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 apply
to all platforms in the future. As a result, the crate is organized
hierarchically based on platform. Each module has a number of `#[cfg]`'d
children, but only one is ever actually compiled. Each module then reexports all
the contents of its children.

This means that for each platform that libc supports, the path from a
leaf 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 a
particular level in the hierarchy means that it is supported on all the child
platforms of that level. For example, when adding a Unix API it should be added
to `src/unix/`, but when adding a Linux-only API it should be added to

If you're not 100% sure at what level of the hierarchy an API should be added
at, fear not! This crate has CI support which tests any binding against all
platforms supported, so you'll see failures if an API is added at the wrong
level 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!

### Test before you commit

We have two automated tests running on [Travis](

1. [`libc-test`](
  - `cd libc-test && cargo test`
  - Use the `skip_*()` functions in `` if you really need a workaround.
2. Style checker
  - `rustc ci/ && ./style src`

### Releasing your change to

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

1. Update the version number in `Cargo.toml`, you'll just be bumping the patch
   version number.
2. Run `cargo update` to regenerate the lockfile to encode your version bump in
   the lock file. You may pull in some other updated dependencies, that's ok.
3. Send a PR to this repository. It should [look like this][example], but it'd
   also be nice to fill out the description with a small rationale for the
   release (any rationale is ok though!)
4. Once merged the release will be tagged and published by one of the libc crate


## Platforms and Documentation

The following platforms are currently tested and have documentation available:

  * [`i686-pc-windows-msvc`](
  * [`x86_64-pc-windows-msvc`](
  * [`i686-pc-windows-gnu`](
  * [`x86_64-pc-windows-gnu`](
  * [`i686-apple-darwin`](
  * [`x86_64-apple-darwin`](
  * `i386-apple-ios`
  * `x86_64-apple-ios`
  * [`i686-unknown-linux-gnu`](
  * [`x86_64-unknown-linux-gnu`](
  * [`x86_64-unknown-linux-musl`](
    (Linux MUSL)
  * [`aarch64-unknown-linux-gnu`](
  * `aarch64-unknown-linux-musl`
    (Linux MUSL)
  * [`sparc64-unknown-linux-gnu`](
  * [`mips-unknown-linux-gnu`](
  * [`arm-unknown-linux-gnueabihf`](
  * [`arm-linux-androideabi`](
  * [`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`](