Cryptographically verifiable, distributed dependency reviews
Add the last reviewed version to Cargo.toml / [dependencies]:
libc = "0.2.139"
Please, use mobile in landscape.
Filter reviews clicking on the numbers in the summary.
Full column names in tooltip hints: rating Negative, rating Neutral, rating Positive, rating Strong, thoroughness, understanding, reviews count.
Compared to 0.2.138, the bulk of the changes are support for new target_os
,nto
, which is QNX/Neutrino. I glanced through them, they seem to have the
right shape. The rest of the changes are the usual: new constants and new
function declarations. The only interesting bit there is a newKERNEL_VERSION
function which emulates the eponymous macro; it returns the
kernel version, limiting the patch version to 255 (for compatibility).
As usual, "thoroughness" for this review is "low" because I didn't manually
check that the bindings match the headers — I trust that the CI checked that
already.
Compared to 0.2.137, this version adds some new constants and bindings. The
only interesting bit is two new wrappers in unix::solarish::compat module
that wrap getpwent_r
and getgrent_r
functions in such a way that calls
don't modify errno
. The wrappers look solid to me.
As usual, "thoroughness" for this review is "low" because I didn't manually
check that the bindings match the headers — I trust that the CI checked that
already.
Compared to 0.2.137, this version adds some new constants and bindings. The
only interesting bit is two new wrappers in unix::solarish::compat module
that wrap getpwent_r
and getgrent_r
functions in such a way that calls
don't modify errno
. The wrappers look solid to me.
As usual, "thoroughness" for this review is "low" because I didn't manually
check that the bindings match the headers — I trust that the CI checked that
already.
Compared to 0.2.135, this version un-deprecates recvmmsg() flags deprecated
by the previous version. It also adds a few constants for madvise(), and
function declarations for dirname() and basename().
As usual, "thoroughness" for this review is "low" because I didn't manually
check that the bindings match the headers — I trust that the CI checked that
already.
Compared to 0.2.135, this version un-deprecates recvmmsg() flags deprecated
by the previous version. It also adds a few constants for madvise(), and
function declarations for dirname() and basename().
As usual, "thoroughness" for this review is "low" because I didn't manually
check that the bindings match the headers — I trust that the CI checked that
already.
Compared to 0.2.135, this version adds more constants, more structs, and more
function declarations. It also deprecates some of recvmmsg() flags, and adds
Apple tvOS as a target to some of Apple calls.
As usual, "thoroughness" for this review is "low" because I didn't manually
check that the bindings match the headers — I trust that the CI checked that
already.
Compared to 0.2.135, this version adds more constants, more structs, and more
function declarations. It also deprecates some of recvmmsg() flags, and adds
Apple tvOS as a target to some of Apple calls.
As usual, "thoroughness" for this review is "low" because I didn't manually
check that the bindings match the headers — I trust that the CI checked that
already.
Compared to 0.2.134, this version adds more consts and function prototypes --
nothing suspicious.
As usual, "thoroughness" for this review is "low" because I didn't manually
check that the bindings match the headers — I trust that the CI checked that
already.
Compared to 0.2.134, this version adds more consts and function prototypes --
nothing suspicious.
As usual, "thoroughness" for this review is "low" because I didn't manually
check that the bindings match the headers — I trust that the CI checked that
already.
Compared to 0.2.133, this tiny update only adds a couple new function
prototypes and a few new constants.
As usual, "thoroughness" for this review is "low" because I didn't manually
check that the bindings match the headers — I trust that the CI checked that
already.
Compared to 0.2.133, this tiny update only adds a couple new function
prototypes and a few new constants.
As usual, "thoroughness" for this review is "low" because I didn't manually
check that the bindings match the headers — I trust that the CI checked that
already.
Compared to 0.2.132, this version adds some new types, structs, consts, and
function prototypes. It also deprecates some constants on FreeBSD.
As usual, "thoroughness" for this review is "low" because I didn't manually
check that the bindings match the headers — I trust that the CI checked that
already.
Compared to 0.2.132, this version adds some new types, structs, consts, and
function prototypes. It also deprecates some constants on FreeBSD.
As usual, "thoroughness" for this review is "low" because I didn't manually
check that the bindings match the headers — I trust that the CI checked that
already.
Compared to 0.2.131, this version fixes one constant, adds another, and
provides one new function signature. That's it.
As usual, "thoroughness" for this review is "low" because I didn't manually
check that the bindings match the headers — I trust that the CI checked that
already.
Compared to 0.2.131, this version fixes one constant, adds another, and
provides one new function signature. That's it.
As usual, "thoroughness" for this review is "low" because I didn't manually
check that the bindings match the headers — I trust that the CI checked that
already.
I'm again rolling two releases into a single review because 0.2.130 was
yanked from crates.io for unknown reason.
Compared to 0.2.129, this version only adds a couple functions for GNU/Linux,
and fixes a type of a constant for Unix newlib. Nothing major at all.
As usual, "thoroughness" for this review is "low" because I didn't manually
check that the bindings match the headers — I trust that the CI checked that
already.
I'm again rolling two releases into a single review because 0.2.130 was
yanked from crates.io for unknown reason.
Compared to 0.2.129, this version only adds a couple functions for GNU/Linux,
and fixes a type of a constant for Unix newlib. Nothing major at all.
As usual, "thoroughness" for this review is "low" because I didn't manually
check that the bindings match the headers — I trust that the CI checked that
already.
I'm rolling two crate releases into a single review because 0.2.128 was
yanked: https://github.com/rust-lang/libc/issues/2866
Compared to 0.2.127, this release just adds some new sructs, consts, and fn
prototypes. It also shuffles around the code responsible for linking on
Android, and adds a workaround for *pintf functions on Windows when linking
with MSVC. All looks okay to me.
As usual, "thoroughness" for this review is "low" because I didn't manually
check that the bindings match the headers — I trust that the CI checked that
already.
I'm rolling two crate releases into a single review because 0.2.128 was
yanked: https://github.com/rust-lang/libc/issues/2866
Compared to 0.2.127, this release just adds some new sructs, consts, and fn
prototypes. It also shuffles around the code responsible for linking on
Android, and adds a workaround for *pintf functions on Windows when linking
with MSVC. All looks okay to me.
As usual, "thoroughness" for this review is "low" because I didn't manually
check that the bindings match the headers — I trust that the CI checked that
already.
Compared to 0.2.126, this release is just bookkeeping. A bunch of new
constants and functions were added, some fixes were applied to existing ones,
and some code was reformatted.
The problem with struct field missing from the Hash
impl that I mentioned
in my previous review has been fixed, too.
As usual, "thoroughness" for this review is "low" because I didn't manually
check that the bindings match the headers — I trust that the CI checked that
already.
Compared to 0.2.126, this release is just bookkeeping. A bunch of new
constants and functions were added, some fixes were applied to existing ones,
and some code was reformatted.
The problem with struct field missing from the Hash
impl that I mentioned
in my previous review has been fixed, too.
As usual, "thoroughness" for this review is "low" because I didn't manually
check that the bindings match the headers — I trust that the CI checked that
already.
Compared to 0.2.125, this is just usual churn. I found a place where a struct
field is used in PartialEq
but not Hash
; I asked the author to check if
that's correct: https://github.com/rust-lang/libc/pull/2748/files#r880853330
Other than that, this looks solid.
As usual, "thoroughness" for this review is "low" because I didn't manually
check that the bindings match the headers — I trust that the CI checked that
already.
Compared to 0.2.125, this is just usual churn. I found a place where a struct
field is used in PartialEq
but not Hash
; I asked the author to check if
that's correct: https://github.com/rust-lang/libc/pull/2748/files#r880853330
Other than that, this looks solid.
As usual, "thoroughness" for this review is "low" because I didn't manually
check that the bindings match the headers — I trust that the CI checked that
already.
Compared to 0.2.124, this release adds more constants, structs, and function
prototypes, plus some support for LoongArch (MIPS-like CPUs from a Chinese
company Loongson).
As usual, "thoroughness" for this review is "low" because I didn't manually
check that the bindings match the headers — I trust that the CI checked that
already.
Compared to 0.2.124, this release adds more constants, structs, and function
prototypes, plus some support for LoongArch (MIPS-like CPUs from a Chinese
company Loongson).
As usual, "thoroughness" for this review is "low" because I didn't manually
check that the bindings match the headers — I trust that the CI checked that
already.
Compared to 0.2.123, this release adds more constants, structs, and function
prototypes. The only interesting bit is si_addr
and si_value
methods forsiginfo_t
on uclibc Linux: they use type punning to interpret siginfo_t
payload differently. They look fine to me.
As usual, "thoroughness" for this review is "low" because I didn't manually
check that the bindings match the headers — I trust that the CI checked that
already.
Compared to 0.2.123, this release adds more constants, structs, and function
prototypes. The only interesting bit is si_addr
and si_value
methods forsiginfo_t
on uclibc Linux: they use type punning to interpret siginfo_t
payload differently. They look fine to me.
As usual, "thoroughness" for this review is "low" because I didn't manually
check that the bindings match the headers — I trust that the CI checked that
already.
Compared to 0.2.122, this release only adds a couple constants and function
signatures.
As usual, "thoroughness" for this review is "low" because I didn't manually
check that the bindings match the headers — I trust that the CI checked that
already.
Compared to 0.2.122, this release only adds a couple constants and function
signatures.
As usual, "thoroughness" for this review is "low" because I didn't manually
check that the bindings match the headers — I trust that the CI checked that
already.
The major change in this release is partial support for __int128 (and similar
types) for aarch64 platforms. As usual with libc, the actual code is
dead-simple; the actual work--verifying that rustc's representation matches
platform's--was done elsewhere. Looks okay to me.
And then there's the usual churn of function declarations and new constants.
As usual, "thoroughness" for this review is "low" because I didn't manually
check that the bindings match the headers — I trust that the CI checked that
already.
The major change in this release is partial support for __int128 (and similar
types) for aarch64 platforms. As usual with libc, the actual code is
dead-simple; the actual work--verifying that rustc's representation matches
platform's--was done elsewhere. Looks okay to me.
And then there's the usual churn of function declarations and new constants.
As usual, "thoroughness" for this review is "low" because I didn't manually
check that the bindings match the headers — I trust that the CI checked that
already.
Compared to 0.2.119, this mostly contains the usual churn: more function
prototypes, some changes to attributes, typo fixes. The only interesting bit
is updates to siginfo_t
on Solarish, where Unix signal payload is now
handled more intelligently. It's admittedly unfinished, but looks okay to me.
As usual, "thoroughness" for this review is "low" because I didn't manually
check that the bindings match the headers — I trust that the CI checked that
already.
Compared to 0.2.119, this mostly contains the usual churn: more function
prototypes, some changes to attributes, typo fixes. The only interesting bit
is updates to siginfo_t
on Solarish, where Unix signal payload is now
handled more intelligently. It's admittedly unfinished, but looks okay to me.
As usual, "thoroughness" for this review is "low" because I didn't manually
check that the bindings match the headers — I trust that the CI checked that
already.
Compared to 0.2.118, this version only adds a few lgrp_* functions for
Solaris-like systems, and a constant on Apple AArch64.
As usual, "thoroughness" for this review is "low" because I didn't manually
check that the bindings match the headers — I trust that the CI checked that
already.
Compared to 0.2.118, this version only adds a few lgrp_* functions for
Solaris-like systems, and a constant on Apple AArch64.
As usual, "thoroughness" for this review is "low" because I didn't manually
check that the bindings match the headers — I trust that the CI checked that
already.
Most of the additions compared to 0.2.117 are related to System V contexts
support. There are also a bunch of new constants, a few new functions, and
a couple typo fixes. Nothing stands out to me in this release.
As usual, "thoroughness" for this review is "low" because I didn't manually
check that the bindings match the headers — I trust that the CI checked that
already.
Most of the additions compared to 0.2.117 are related to System V contexts
support. There are also a bunch of new constants, a few new functions, and
a couple typo fixes. Nothing stands out to me in this release.
As usual, "thoroughness" for this review is "low" because I didn't manually
check that the bindings match the headers — I trust that the CI checked that
already.
Compared to 0.2.116, this version removes the "How to apply the Apache
license to your work" appendix from the LICENSE file, and adds a bunch of
constants for Android and musl. Nothing hairy.
As usual, "thoroughness" for this review is "low" because I didn't manually
check that the bindings match the headers — I trust that the CI checked that
already.
Compared to 0.2.116, this version removes the "How to apply the Apache
license to your work" appendix from the LICENSE file, and adds a bunch of
constants for Android and musl. Nothing hairy.
As usual, "thoroughness" for this review is "low" because I didn't manually
check that the bindings match the headers — I trust that the CI checked that
already.
Compared to 0.2.115, this version is mostly about ARMv6K Nintendo 3DS
support, but it also adds a number of new constants and a couple functions.
Nothing scary.
As usual, "thoroughness" for this review is "low" because I didn't manually
check that the bindings match the headers — I trust that the CI checked that
already.
Compared to 0.2.115, this version is mostly about ARMv6K Nintendo 3DS
support, but it also adds a number of new constants and a couple functions.
Nothing scary.
As usual, "thoroughness" for this review is "low" because I didn't manually
check that the bindings match the headers — I trust that the CI checked that
already.
Compared to 0.2.114, this version adds one new constant, a couple new types,
and a few new structs. Looks legit.
As usual, "thoroughness" for this review is "low" because I didn't manually
check that the bindings match the headers — I trust that the CI checked that
already.
Compared to 0.2.114, this version adds one new constant, a couple new types,
and a few new structs. Looks legit.
As usual, "thoroughness" for this review is "low" because I didn't manually
check that the bindings match the headers — I trust that the CI checked that
already.
The diff from 0.2.113 only shows the usual churn: some constants got moved,
some functions got added, and one macro got fixed.
As usual, "thoroughness" for this review is "low" because I didn't manually
check that the bindings match the headers — I trust that the CI checked that
already.
The diff from 0.2.113 only shows the usual churn: some constants got moved,
some functions got added, and one macro got fixed.
As usual, "thoroughness" for this review is "low" because I didn't manually
check that the bindings match the headers — I trust that the CI checked that
already.
The diff from 0.2.111 reveals nothing malicious, just the usual churn.
As usual, "thoroughness" for this review is "low" because I didn't manually
check that the bindings match the headers — I trust that the CI checked that
already.
The diff from 0.2.111 reveals nothing malicious, just the usual churn.
As usual, "thoroughness" for this review is "low" because I didn't manually
check that the bindings match the headers — I trust that the CI checked that
already.
The diff from 0.2.111 reveals nothing malicious.
As usual, "thoroughness" for this review is "low" because I didn't manually
check that the bindings match the headers — I trust that the CI checked that
already.
The diff from 0.2.111 reveals nothing malicious.
As usual, "thoroughness" for this review is "low" because I didn't manually
check that the bindings match the headers — I trust that the CI checked that
already.
The diff from 0.2.110 is minuscule: just some BSD functions moved around, and
a new linker dependency added for FreeBSD.
As usual, "thoroughness" for this review is "low" because I didn't manually
check that the bindings match the headers — I trust that the CI checked that
already.
The diff from 0.2.110 is minuscule: just some BSD functions moved around, and
a new linker dependency added for FreeBSD.
As usual, "thoroughness" for this review is "low" because I didn't manually
check that the bindings match the headers — I trust that the CI checked that
already.
The diff from 0.2.109 contains all the usual stuff: some new FreeBSD work,
some deprecation removals, plus a bit of new misc stuff. Nothing malicious
as far as I can tell.
As usual, "thoroughness" for this review is "low" because I didn't manually
check that the bindings match the headers — I trust that the CI checked that
already.
The diff from 0.2.109 contains all the usual stuff: some new FreeBSD work,
some deprecation removals, plus a bit of new misc stuff. Nothing malicious
as far as I can tell.
As usual, "thoroughness" for this review is "low" because I didn't manually
check that the bindings match the headers — I trust that the CI checked that
already.
The diff from 0.2.108 shows nothing malicious.
As usual, "thoroughness" for this review is "low" because I didn't manually
check that the bindings match the headers — I trust that the CI checked that
already.
The diff from 0.2.108 shows nothing malicious.
As usual, "thoroughness" for this review is "low" because I didn't manually
check that the bindings match the headers — I trust that the CI checked that
already.
The diff from 0.2.107 is large but boring. I didn't find anything malicious.
I did find a couple insignificant errors:
As usual, "thoroughness" for this review is "low" because I didn't manually
check that the bindings match the headers — I trust that the CI checked that
already.
The diff from 0.2.107 is large but boring. I didn't find anything malicious.
I did find a couple insignificant errors:
As usual, "thoroughness" for this review is "low" because I didn't manually
check that the bindings match the headers — I trust that the CI checked that
already.
The diff from 0.2.107 doesn't contain anything unusual or malicious.
As usual, "thoroughness" for this review is "low" because I didn't manually
check that the bindings match the headers — I trust that the CI checked that
already.
The diff from 0.2.107 doesn't contain anything unusual or malicious.
As usual, "thoroughness" for this review is "low" because I didn't manually
check that the bindings match the headers — I trust that the CI checked that
already.
The diff from 0.2.106 reveals nothing unusual or malicious.
As usual, "thoroughness" for this review is "low" because I didn't manually
check that the bindings match the headers — I trust that the CI checked that
already.
The diff from 0.2.106 reveals nothing unusual or malicious.
As usual, "thoroughness" for this review is "low" because I didn't manually
check that the bindings match the headers — I trust that the CI checked that
already.
BASIC LIBRARY
libc is the absolute basic core crate for the rust language.
I trust it just like I trust the Rust standard library or the rust compiler.
I didn't review the source code.
Published to crates.io by: JohnTitor (Libc crate team)
The diff from 0.2.104 only contains the usual churn, nothing malicious. Some
new entries have doc comments, that's unusual for this crate :)
As usual, "thoroughness" for this review is "low" because I didn't manually
check that the bindings match the headers — I trust that the CI checked that
already.
The diff from 0.2.104 only contains the usual churn, nothing malicious. Some
new entries have doc comments, that's unusual for this crate :)
As usual, "thoroughness" for this review is "low" because I didn't manually
check that the bindings match the headers — I trust that the CI checked that
already.
BASIC LIBRARY
libc is the absolute basic core crate for the rust language.
I trust it just like I trust the Rust standard library or the rust compiler.
I didn't review the source code.
Published to crates.io by: JohnTitor (Libc crate team)
Half of the diff since 0.2.103 is bindings for the new rustc target, SOLID.
The other half is the usual: more constants, some more bindings.
As usual, "thoroughness" for this review is "low" because I didn't manually
check that the bindings match the headers — I trust that the CI checked that
already.
Half of the diff since 0.2.103 is bindings for the new rustc target, SOLID.
The other half is the usual: more constants, some more bindings.
As usual, "thoroughness" for this review is "low" because I didn't manually
check that the bindings match the headers — I trust that the CI checked that
already.
BASIC LIBRARY
libc is the absolute basic core crate for the rust language.
I trust it just like I trust the Rust standard library or the rust compiler.
I didn't review the source code.
Published to crates.io by: Amanieu (Libc crate team)
The diff from 0.2.102 doesn't reveal anything malicious.
As usual, "thoroughness" for this review is "low" because I didn't manually
check that the bindings match the headers — I trust that the CI checked that
already.
The diff from 0.2.102 doesn't reveal anything malicious.
As usual, "thoroughness" for this review is "low" because I didn't manually
check that the bindings match the headers — I trust that the CI checked that
already.
BASIC LIBRARY
libc is the absolute basic core crate for the rust language.
I trust it just like I trust the Rust standard library or the rust compiler.
I didn't review the source code.
Published to crates.io by: JohnTitor (Libc crate team)
The diff from 0.2.101 doesn't show anything malicious.
Funny typo: "errnoeously". Not worth reporting and fixing upstream, I think.
As usual, "thoroughness" for this review is "low" because I didn't manually
check that the bindings match the headers — I trust that the CI checked that
already.
The diff from 0.2.101 doesn't show anything malicious.
Funny typo: "errnoeously". Not worth reporting and fixing upstream, I think.
As usual, "thoroughness" for this review is "low" because I didn't manually
check that the bindings match the headers — I trust that the CI checked that
already.
BASIC LIBRARY
libc is the absolute basic core crate for the rust language.
I trust it just like I trust the Rust standard library or the rust compiler.
I didn't review the source code.
Published to crates.io by: Amanieu (Libc crate team)
The diff from 0.2.100 doesn't show anything malicious.
As usual, "thoroughness" for this review is "low" because I didn't manually
check that the bindings match the headers — I trust that the CI checked that
already.
The diff from 0.2.100 doesn't show anything malicious.
As usual, "thoroughness" for this review is "low" because I didn't manually
check that the bindings match the headers — I trust that the CI checked that
already.
BASIC LIBRARY
libc is the absolute basic core crate for the rust language.
I trust it just like I trust the Rust standard library or the rust compiler.
I didn't review the source code.
Published to crates.io by: JohnTitor (Libc crate team)
The diff from 0.2.99 doesn't show anything malicious.
As usual, "thoroughness" for this review is "low" because I didn't manually
check that the bindings match the headers — I trust that the CI checked that
already.
The diff from 0.2.99 doesn't show anything malicious.
As usual, "thoroughness" for this review is "low" because I didn't manually
check that the bindings match the headers — I trust that the CI checked that
already.
BASIC LIBRARY
libc is the absolute basic core crate for the rust language.
I trust it just like I trust the Rust standard library or the rust compiler.
I didn't review the source code.
Published to crates.io by: JohnTitor (Libc crate team)
The diff from 0.2.98 doesn't reveal anything malicious. I found a couple
typos though, and submitted a PR to fix them:
https://github.com/rust-lang/libc/pull/2330
As usual, "thoroughness" for this review is "low" because I didn't manually
check that the bindings match the headers — I trust that the CI checked that
already.
The diff from 0.2.98 doesn't reveal anything malicious. I found a couple
typos though, and submitted a PR to fix them:
https://github.com/rust-lang/libc/pull/2330
As usual, "thoroughness" for this review is "low" because I didn't manually
check that the bindings match the headers — I trust that the CI checked that
already.
BASIC LIBRARY
libc is the absolute basic core crate for the rust language.
I trust it just like I trust the Rust standard library or the rust compiler.
I didn't review the source code.
Published to crates.io by: JohnTitor (Libc crate team)
The diff from 0.2.97 doesn't reveal anything suspicious.
As usual, "thoroughness" for this review is "low" because I didn't manually
check that the bindings match the headers — I trust that the CI checked that
already.
The diff from 0.2.97 doesn't reveal anything suspicious.
As usual, "thoroughness" for this review is "low" because I didn't manually
check that the bindings match the headers — I trust that the CI checked that
already.
BASIC LIBRARY
libc is the absolute basic core crate for the rust language.
I trust it just like I trust the Rust standard library or the rust compiler.
I didn't review the source code.
Published to crates.io by: JohnTitor (Libc crate team)
Compared to 0.2.95, there are two new functions (mallinfo2 and mstats) along
with their respective structs, and one new constant (AF_VSOCK).
Nothing fancy. As usual, "thoroughness" for this review is "low" because
I didn't manually check that the bindings match the headers — I trust that
the CI checked that already.
Compared to 0.2.95, there are two new functions (mallinfo2 and mstats) along
with their respective structs, and one new constant (AF_VSOCK).
Nothing fancy. As usual, "thoroughness" for this review is "low" because
I didn't manually check that the bindings match the headers — I trust that
the CI checked that already.
Delta from 0.2.95 doesn't show anything malicious, just the usual stuff: more
bindings, more constants, more types.
This looks fine. As usual, "thoroughness" for this review is "low" because
I didn't manually check that the bindings match the headers — I trust that
the CI checked that already.
Delta from 0.2.95 doesn't show anything malicious, just the usual stuff: more
bindings, more constants, more types.
This looks fine. As usual, "thoroughness" for this review is "low" because
I didn't manually check that the bindings match the headers — I trust that
the CI checked that already.
BASIC LIBRARY
libc is the absolute basic core crate for the rust language.
I trust it just like I trust the Rust standard library or the rust compiler.
I didn't review the source code.
Published to crates.io by: JohnTitor (Libc crate team)
Delta from 0.2.94 reveals nothing unusual: add new bindings, add new
constants, move some code around, and undo a macOS-related hack that
I committed earlier. Some FIXMEs were added too, but their comments don't
sound urgent.
This looks fine. "Thoroughness" for this review is "low" because I didn't
manually check that the bindings match the headers — I trust that the CI
checked that already.
Delta from 0.2.94 reveals nothing unusual: add new bindings, add new
constants, move some code around, and undo a macOS-related hack that
I committed earlier. Some FIXMEs were added too, but their comments don't
sound urgent.
This looks fine. "Thoroughness" for this review is "low" because I didn't
manually check that the bindings match the headers — I trust that the CI
checked that already.
BASIC LIBRARY
libc is the absolute basic core crate for the rust language.
I trust it just like I trust the Rust standard library or the rust compiler.
I didn't review the source code.
Published to crates.io by: JohnTitor (Libc crate team)
Delta from 0.2.93 moves some TCP-related constants around, adds
RLIMIT_NLIMITS constant, and provides a few new function bindings.
This looks fine. "Thoroughness" for this review is "low" because I didn't
manually check that the bindings match the headers — I trust that the CI
checked that already.
Delta from 0.2.93 moves some TCP-related constants around, adds
RLIMIT_NLIMITS constant, and provides a few new function bindings.
This looks fine. "Thoroughness" for this review is "low" because I didn't
manually check that the bindings match the headers — I trust that the CI
checked that already.
Delta from 0.2.92 consists mostly of two things: formatting changes, and
modularisation of some architecture-specific constants for Linux.
Packing was disabled for arphdr
and in_addr
on NetBSD. The commit message
sounds convincing to me
(https://github.com/rust-lang/libc/commit/ec13c82bc93070dfe1d81a359174e0495edfe487).
There's also a hint at a new CI machinery that'll ensure the crate doesn't
break semver.
Overall this looks fine to me. As usual, I rely on the project's CI to check
that the bindings match C, hence "thoroughness" is low.
Delta from 0.2.92 consists mostly of two things: formatting changes, and
modularisation of some architecture-specific constants for Linux.
Packing was disabled for arphdr
and in_addr
on NetBSD. The commit message
sounds convincing to me
(https://github.com/rust-lang/libc/commit/ec13c82bc93070dfe1d81a359174e0495edfe487).
There's also a hint at a new CI machinery that'll ensure the crate doesn't
break semver.
Overall this looks fine to me. As usual, I rely on the project's CI to check
that the bindings match C, hence "thoroughness" is low.
Delta from 0.2.91 mostly moves code around by adding const
annotations. It
also introduces one new bindings (pwrite64). Nothing suspicious. As usual,
I rely on the project's CI to check that the bindings match C, hence
"thoroughness" is low.
Delta from 0.2.91 mostly moves code around by adding const
annotations. It
also introduces one new bindings (pwrite64). Nothing suspicious. As usual,
I rely on the project's CI to check that the bindings match C, hence
"thoroughness" is low.
Delta from 0.2.90 only adds a single constant to a couple modules and edits
some docs. Looks okay to me. (As usual, I rely on the project's CI to check
if the constant is correct, hence "thoroughness" is low).
Delta from 0.2.90 only adds a single constant to a couple modules and edits
some docs. Looks okay to me. (As usual, I rely on the project's CI to check
if the constant is correct, hence "thoroughness" is low).
I checked that the delta from 0.2.89 doesn't add any suspicious code. It
indeed doesn't. I trust that ctest in the project's CI checked that all new
constants have the expected values, and that function signatures match C.
I checked that the delta from 0.2.89 doesn't add any suspicious code. It
indeed doesn't. I trust that ctest in the project's CI checked that all new
constants have the expected values, and that function signatures match C.
This crate contains unsafe bindings to platform-specific C functions. The
project has an expansive CI pipeline that runs ctest on Linux, macOS,
FreeBSD, and Windows. Where possible, the testing is done on multiple
architectures with different libc implementations.
Most of the crate is marked unsafe, but that's just the nature of the beast.
I only looked at one module, unix, so thoroughness is capped at "low".
However, the crate comes from the same people who build Rust itself, so this
doesn't affect the rating.
Given it's just a list of declarations, which are then automatically checked,
I'm fairly confident that this code does what it's supposed to do.
This crate contains unsafe bindings to platform-specific C functions. The
project has an expansive CI pipeline that runs ctest on Linux, macOS,
FreeBSD, and Windows. Where possible, the testing is done on multiple
architectures with different libc implementations.
Most of the crate is marked unsafe, but that's just the nature of the beast.
I only looked at one module, unix, so thoroughness is capped at "low".
However, the crate comes from the same people who build Rust itself, so this
doesn't affect the rating.
Given it's just a list of declarations, which are then automatically checked,
I'm fairly confident that this code does what it's supposed to do.
Used by almost everyone
Used by almost everyone
BASIC LIBRARY
libc is the absolute basic core crate for the rust language.
I trust it just like I trust the Rust standard library or the rust compiler.
I didn't review the source code.
Published to crates.io by: Amanieu (Libc crate team)
BASIC LIBRARY
libc is the absolute basic core crate for the rust language.
I trust it just like I trust the Rust standard library or the rust compiler.
I didn't review the source code.
Published to crates.io by: JohnTitor (Libc crate team)
BASIC LIBRARY
libc is the absolute basic core crate for the rust language.
I trust it just like I trust the Rust standard library or the rust compiler.
I didn't review the source code.
Published to crates.io by: JohnTitor (Libc crate team)
BASIC LIBRARY
libc is the absolute basic core crate for the rust language.
I trust it just like I trust the Rust standard library or the rust compiler.
I didn't review the source code.
Published to crates.io by: JohnTitor (Libc crate team)
BASIC LIBRARY
libc is the absolute basic core crate for the rust language.
I trust it just like I trust the Rust standard library or the rust compiler.
I didn't review the source code.
Published to crates.io by: joshtriplett (Libc crate team)
BASIC LIBRARY
libc is the absolute basic core crate for the rust language.
I trust it just like I trust the Rust standard library or the rust compiler.
I didn't review the source code.
Published to crates.io by: JohnTitor (Libc crate team)
BASIC LIBRARY
libc is the absolute basic core crate for the rust language.
I trust it just like I trust the Rust standard library or the rust compiler.
I didn't review the source code.
Published to crates.io by: JohnTitor (Libc crate team)
BASIC LIBRARY
libc is the absolute basic core crate for the rust language.
I trust it just like I trust the Rust standard library or the rust compiler.
I didn't review the source code.
Published to crates.io by: JohnTitor (Libc crate team)
BASIC LIBRARY
libc is the absolute basic core crate for the rust language.
I trust it just like I trust the Rust standard library or the rust compiler.
I didn't review the source code.
Published to crates.io by: JohnTitor (Libc crate team)
BASIC LIBRARY
libc is the absolute basic core crate for the rust language.
I trust it just like I trust the Rust standard library or the rust compiler.
I didn't review the source code.
Published to crates.io by: JohnTitor (Libc crate team)
BASIC LIBRARY
libc is the absolute basic core crate for the rust language.
I trust it just like I trust the Rust standard library or the rust compiler.
I didn't review the source code.
Published to crates.io by: JohnTitor (Libc crate team)
BASIC LIBRARY
libc is the absolute basic core crate for the rust language.
I trust it just like I trust the Rust standard library or the rust compiler.
I didn't review the source code.
Published to crates.io by: JohnTitor (Libc crate team)
BASIC LIBRARY
libc is the absolute basic core crate for the rust language.
I trust it just like I trust the Rust standard library or the rust compiler.
I didn't review the source code.
Published to crates.io by: JohnTitor (Libc crate team)
© bestia.dev 2023, MIT License, Version: 2023.608.1636
Open source repository for this web app: https://github.com/bestia-dev/cargo_crev_web/
Compared to 0.2.138, the bulk of the changes are support for new
target_os
,nto
, which is QNX/Neutrino. I glanced through them, they seem to have theright shape. The rest of the changes are the usual: new constants and new
function declarations. The only interesting bit there is a new
KERNEL_VERSION
function which emulates the eponymous macro; it returns thekernel version, limiting the patch version to 255 (for compatibility).
As usual, "thoroughness" for this review is "low" because I didn't manually
check that the bindings match the headers — I trust that the CI checked that
already.