Gitiles
Code Review Sign In
gerrit-public.fairphone.software / platform / external / rust / crates / libc / 68d4848fe6ecce158f0a4fb821efdc68219ef88c
commit68d4848fe6ecce158f0a4fb821efdc68219ef88c[log] [tgz]
authorbors <bors@rust-lang.org>Fri Mar 02 01:19:11 2018 +0000
committerbors <bors@rust-lang.org>Fri Mar 02 01:19:11 2018 +0000
tree01117824b2cd999609a3d6ce3e26af99b97bb5ba
parentf0938610e56c27403e8bc63e131269a06c0a95f7 [diff]
parent78f93220d70e796ba4a3ab8482d0f57be763e8c2 [diff]
Auto merge of #937 - bdrewery:freebsd-ino64-compat, r=alexcrichton

Use pre-ino64 FreeBSD symbols to resolve binary compatibility.

This follows the same method as other platforms like OSX and NetBSD.

This will fix rustup and building from git (once libc is updated for bootstrap)
on FreeBSD12 post-ino64 in https://github.com/freebsd/freebsd/commit/f713b08c027de35b0b8ed9990eabc32e100bee7a.
It also avoids having to hotpatch the stage0 compiler, and HOME/.cargo
libc files on FreeBSD12 to build rust.

The only real pitfall is that this will prevent interaction with inodes that
have an ino_t above the 32-bit limit due to truncation.  On the other hand
Rust won't work at all on 12 without doing this currently.  In general
it should not be a problem for users and if they need 64-bit ino_t they
can use a patched libc, rather than the current state of affairs in
requiring a patched libc to use Rust on 12.

A better, or complementary, approach would be something like proposed in
https://github.com/rust-lang/rfcs/pull/2048 to allow targetting a specific
version of FreeBSD. This would allow Rust to default to this compatibility
mode by targetting FreeBSD10 and still allow targetting FreeBSD12 for 64-bit
ino_t.

The symbol versions used were taken from the old version in
https://github.com/freebsd/freebsd/commit/f713b08c027de35b0b8ed9990eabc32e100bee7a#diff-61a32fcfb7ecd4517665fed591813c57
and
https://github.com/freebsd/freebsd/commit/f713b08c027de35b0b8ed9990eabc32e100bee7a#diff-7f67ccf8b5f44ff2f54eaab0207abb8d.

The scope of functions versioned here differs from other platforms as
not all structs were modified that were on others, such as DIR for
`opendir`, `telldir`, etc.  Only functions using dirent, stat, glob_t,
and dev_t need the changes.

Fixes https://github.com/rust-lang/rust/issues/42681
tree: 01117824b2cd999609a3d6ce3e26af99b97bb5ba
  1. ci/
  2. libc-test/
  3. src/
  4. .gitignore
  5. .travis.yml
  6. appveyor.yml
  7. Cargo.lock
  8. Cargo.toml
  9. LICENSE-APACHE
  10. LICENSE-MIT
  11. README.md
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

Usage

First, add the following to your Cargo.toml:

[dependencies]
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:

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

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.

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!

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 build.rs if you really need a workaround.
  1. Style checker
  • rustc ci/style.rs && ./style src

Releasing your change to crates.io

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:

  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, 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 maintainers.

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: