Gitiles
Code Review Sign In
gerrit-public.fairphone.software / platform / external / rust / crates / libc / ef20ddbc57c7e6593ecc48ab016b43792204c0cf
commitef20ddbc57c7e6593ecc48ab016b43792204c0cf[log] [tgz]
authorJon Gjengset <jon@thesquareplanet.com>Wed Apr 26 22:39:52 2017 -0400
committerJon Gjengset <jon@thesquareplanet.com>Fri Apr 28 10:58:25 2017 -0400
tree573423e19a755e60e5fc7e534625ab02fe438819
parent288ed55dd75ec89b3d56efca198ee7c0be98906d [diff]
Add binding for res_init.

Some notes about the particularities of the changes:

res_init has been deprecated in favor of res_ninit, and many (but not
all) targets have therefore renamed the link name to __res_init. For
example, this happened in glibc in version 2.2:
https://bugzilla.redhat.com/show_bug.cgi?id=43822#c6
In these systems, res_init is #defined to __res_init in resolv.h, which
lets existing C programs continue to be compiled.

Unfortunately, this define doesn't automatically apply to our Rust code.
We therefore need to manually map the link name of res_init as
appropriate for each target:

macOS and iOS use res_9_init: https://github.com/practicalswift/osx/blob/3908694d6328baa293f0d7fc337348c01d13ed8f/src/libresolv/resolv.h#L316
Solaris uses res_init: https://java.net/projects/solaris/sources/on-src/content/usr/src/head/resolv.h
OpenBSD uses __res_init: https://github.com/openbsd/src/blob/f3b3b7c7ca9a921db3a5650eed40f2b2e4d731d8/include/resolv.h#L268
FreeBSD uses __res_init: https://github.com/freebsd/freebsd/blob/6911f4a88c9832e5985b788f5e84010424f9e020/include/resolv.h#L290
NetBSD uses __res_init: http://ftp.netbsd.org/pub/NetBSD/NetBSD-current/src/include/resolv.h
glibc uses __res_init: https://github.com/lattera/glibc/blob/a2f34833b1042d5d8eeb263b4cf4caaea138c4ad/resolv/resolv.h#L259
eglibc uses __res_init: https://github.com/Xilinx/eglibc/blob/7f0bcce417c47aefad06ddfec7cd4ced3a4e10ff/resolv/resolv.h#L259
musl uses res_init: https://github.com/runtimejs/musl-libc/blob/0a11d7cb13e243782da36e2e5747b8b151933cca/include/resolv.h#L128
Android uses res_init: https://github.com/android/platform_bionic/blob/306ea559528255e19a5bcd68cc2a9b1afc2cfb27/libc/include/resolv.h#L57

One caveat here is that NetBSD doesn't seem to use the symbol name
__res_init yet, despite the redefine being present in resolv.h. At least
Travis fails for the netbsd target if __res_init is used. This may
change in the future.

iOS and macOS both unfortunately require linking with libresolv, despite
the symbols technically being available without libresolv:
resolv: http://blog.achernya.com/2013/03/os-x-has-silly-libsystem.html
Android and OpenBSD fall in the same category.
2 files changed
tree: 573423e19a755e60e5fc7e534625ab02fe438819
  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 run
  • Use the skip_*() functions in build.rs if you really need a workaround.
  1. Style checker
  • rustc ci/style.rs && ./style src

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: