OpenE2K/libc-rs
2
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity
213 Commits 2 Branches 0 Tags 10 MiB
Rust 98%
Shell 1%
Dockerfile 0.7%
CSS 0.3%
524e137402
Go to file
Alex Crichton 524e137402 Add numbered steps to add an API
2015-10-29 11:57:29 -07:00
ci Run more extra targets on nightly 2015-10-29 11:08:34 -07:00
libc-test iOS support 2015-09-21 14:37:14 -07:00
src Improve the README and switch URLs 2015-10-29 11:54:12 -07:00
.gitignore Ignore .cargo 2015-09-18 18:51:25 -07:00
.travis.yml Run more extra targets on nightly 2015-10-29 11:08:34 -07:00
appveyor.yml AppVeyor has MSYS2 installed by default now! 2015-10-07 14:38:47 -07:00
Cargo.toml Move linkage to specific modules 2015-09-15 17:30:53 -07:00
LICENSE-APACHE
LICENSE-MIT
README.md Add numbered steps to add an API 2015-10-29 11:57:29 -07:00

README.md

libc

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

Build Status Build status

[Documentation][#Platforms-and-Documentation]

Usage

First, add the following to your Cargo.toml:

[dependencies]
libc = "1.0"

Next, add this to your crate root:

extern crate libc;

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.

Adding an API

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

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/mod.rs, but when adding a Linux-only API it should be added to src/unix/notbsd/linux/mod.rs.

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!

Platforms and Documentation

The following platforms are currently tested and have documentation available:

Tested:

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

  • x86_64-unknown-freebsd
  • i686-unknown-freebsd
  • x86_64-unknown-bitrig
  • x86_64-unknown-dragonfly
  • x86_64-unknown-openbsd
  • x86_64-unknown-netbsd