vasilito
f02504b863
version = "0.2.189" -> "0.2.189+rb0.3.2", per local/AGENTS.md "Version conventions": every Cat 2 fork is <upstream>+rb<branch>. The label is what makes the fork traceable to both its upstream base and the Red Bear branch it was built for. +rb is build metadata, which semver ignores when matching, so ^0.2 requirements still resolve to the fork -- confirmed, the rust lockfile now reads libc v0.2.189+rb0.3.2 from the path source. A -rb suffix would be read as a pre-release and would NOT satisfy them, which is exactly why the project mandates +rb. Two things this surfaced: - fork-upstream-map: libc moved from snapshot to diverged. The fork is vendored from the crates.io PACKAGE, whose file set differs from the upstream git tag by construction (no .github/, adds .cargo_vcs_info.json), so a tag content-diff reported differences that mean nothing -- 'missing files that exist in upstream' for files the package never ships. diverged states the real relationship. - local/recipes/dev/gcc16/.vendored-upstream added. Extracting GCC 16.1.0 put upstream's vendored Rust crates under local/recipes/*/source/, so sync-versions.sh treated datafrog/log/polonius-engine as Cat 1 in-house crates and wanted to stamp them 0.3.2. The marker is the documented escape hatch (BUILD-SYSTEM.md section 7). Both gates clean: verify-fork-versions reports no violations, sync-versions --check reports no gcc16 drift.
libc - Raw FFI bindings to platforms' system libraries
libc provides 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 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.
Windows API bindings are not included in this crate. If you are looking for WinAPI bindings, consider using crates like windows-sys.
More detailed information about the design of this library can be found in its associated RFC.
v1.0 Roadmap
Currently, libc has two active branches: main for the upcoming v1.0 release,
and libc-0.2 for the currently published version. By default all pull requests
should target main; once reviewed, they can be cherry picked to the libc-0.2
branch if needed.
We will stop making new v0.2 releases once v1.0 is released.
See the section in CONTRIBUTING.md for more details.
Usage
Add the following to your Cargo.toml:
[dependencies]
libc = "0.2"
Rust version support
The minimum supported Rust toolchain version is currently Rust 1.65.
Increases to the MSRV are allowed to change without a major (i.e. semver- breaking) release in order to avoid a ripple effect in the ecosystem. A policy for when this may change is a work in progress.
libc may continue to compile with Rust versions older than the current MSRV
but this is not guaranteed.
Platform support
You can see the platform(target)-specific docs on docs.rs, select a platform you want to see.
See ci/verify-build.py for
the platforms on which libc is guaranteed to build for each Rust toolchain.
The test matrices at GitHub Actions show the platforms in which libc tests
are run.
License
This project is licensed under either of
at your option.
Contributing
We welcome all people who want to contribute. Please see the contributing instructions for more information.
Contributions in any form (issues, pull requests, etc.) to this project must adhere to Rust's Code of Conduct.
Unless you explicitly state otherwise, any contribution intentionally submitted
for inclusion in libc by you, as defined in the Apache-2.0 license, shall be
dual licensed as above, without any additional terms or conditions.