<sup>1</sup>: Note that this list has nothing to do with any Unix or Posix
standard, it's just a list shared between all OSs that declare `#[cfg(unix)]`.
We have two automated tests running on [GitHub Actions](https://github.com/rust-lang/libc/actions):
1. - -2. -
Sometimes an upstream adds a breaking change to their API e.g. removing outdated items,
changing the type signature, etc. And we probably should follow that change to build the
`libc` crate successfully. It's annoying to do the equivalent of semver-major versioning
for each such change. Instead, we mark the item as deprecated and do the actual change
after a certain period. The steps are:
1. - -2.
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
crates.io! 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:
Welcome! If you are reading this document, it means you are interested in contributing
to the `libc` crate.
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/mod.rs`, 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.
New symbol(s) (i.e. functions, constants etc.) should also be added to the
symbols list(s) found in the `libc-test/semver` directory. These lists keep
track of what symbols are public in the libc crate and ensures they remain
available between changes to the crate. If the new symbol(s) are available on
all supported Unixes it should be added to `unix.txt` list<sup>1</sup>,
otherwise they should be added to the OS specific list(s).
With that in mind, the steps for adding a new API are: