libc
rustix
libc | rustix | |
---|---|---|
10 | 15 | |
1,966 | 1,321 | |
1.1% | 1.7% | |
9.4 | 9.4 | |
5 days ago | 9 days ago | |
Rust | Rust | |
Apache License 2.0 | GNU General Public License v3.0 or later |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
libc
-
Pragmatic Versioning – An Alternative to Semver
> I absolutely don't see how this is a problem with semver,
Strange to not see it. Semver promises to solve dependency hell. In the example everyone correctly followed the sevmver and the app is broken by a dependency hell issue.
> it is not the responsibility of semver to tell a language how packages should be isolated and loaded. That is a problem of a) the language and b) dependency resolution in the package manager.
So semver only works for "good" languages?
> Bundler, by design, does not allow the above, instead having a flat, consistent vision of dependencies.
Ok, so what happens with the app when packages managed by Bundler get fragmented by depending on an incompatible version of sub-dependency (commons-logging 1.1.1 vs 2.0.1 as in the example)?
Also note, even for languages and tooling supporting multiple library versions loaded side by side, there are scenarios where things break.
For example, the "libc apocalypse" situation in Rust https://github.com/rust-lang/libc/issues/547
Here after the "libc" module released a major version, the definition for the `void` C type in two versions of the lib are considered by the compiler as two different types, resulting in breakages everywhere around the library ecosystem.
There are also scenarios for dynamic languages / runtime errors.
> None of this is the responsibility of semver. In fact, semver would help the language provide tooling to detect that kind of "hey this instance is from foo-1.0 but you're trying to consume it in foo-2.0".
And what's next after it detected the dependency hell? It's too late and the person suffering is not in the position to fix it. You have to upgrade to "authentication 1.1.2" for security compliance, because the version 1.1.1 has known vulnerabilities. But that breaks the application, because the maintainer of the lower level dependency "commons-logging" follows semantic versioning.
The promise was to prevent dependency hell, not to detect it.
Quoting the ticket and reiterating the point of my first comment above:
Once again, the point of this ticket is to:
Remove the false promise that SemVer solves dependency hell by simply increasing major version.
-
Semantic Versioning 2.0.0 – Semantic Versioning
Even if coexistence of multiple library versions is supported, there are scenarios where things break.
For example, the "libc apocalypse" situation in Rust https://github.com/rust-lang/libc/issues/547
Here after the "libc" module released a major version, the definition for the `void` C type in two versions of the lib are considered by the compiler as two different types, resulting in breakages everywhere around the library ecosystem.
There are also scenarios for dynamic languages / runtime errors in statically typed languages.
My main problem with the current SemVer spec, is that it does not mention multiple lib versions problem, and promises the dependency hell issues can be solved simply by updating major version number. Thus encouraging to break backward compatibility freely.
Also note, it's not the case that SemVer is intended only for languages supporting multiple library versions. The SemVer is a product of Ruby community, and Ruby has a global namespace for classes and unable to have several versions of a lib simultaneously.
In 2000s they were breaking compatibility left and right, neglecting elementary compatibility practices. If you were working on an application, practically every time when you update dependencies, something would break.
So (in 2011 ?) they came out with this "manifesto" (Why such a big name? This scheme of versioning was well established in linkers and sonames of all Unix-like systems for decades - it goes back to at least 1987 paper "Shared Libraries in SunOS").
It's a good thing SemVer acknowledges finally that compatibility is a serious matter. Only that it's better to discourage compatibility breakages. An in cases when it's really needed (I agree such cases exists), there are things to take care of in addition to simply increase major version num.
-
Can rust be entirely written in rust and drop C usage in its code base ?
The libc crate exposes system C APIs in Rust code, and is used by the compiler and standard library. It also does not contain any C code. See for yourself.
-
7 ways to pass a string between 🦀 Rust and C
Ok, what if we are sure that our C code would use a given version of malloc/free only to allocate memory (are we ever sure about anything like that is out of the scope of the article)? Well, in this case we are brave enough to use libc crate in our rust code:
-
A generalized guide on porting std to a unix like platform?
Port libc. I recommend using bindgen for this.
-
When does the libc crate link with the build target’s libc?
While looking at the libc crate and its build script, I don’t quite understand when or how the crate’s libc definitions link to the build target’s actual libc.
-
What do you think about Zig?
For what it's worth, there's been discussion of this not only for glibc on Linux but also for BSDs which take many more liberties with API and ABI compatibility to keep their technical debt low. I can't summarise the years of discussion here but I encourage anyone interested to read through https://github.com/rust-lang/libc/issues/570
- Integrating Rust into the Android Open Source Project
-
Giving ADA a Chance
In answer to what appears to be a misunderstanding about Rust:
> Its foreign function interface seems particularly poorly implemented. The official Rust documentation suggests the use of the external third-party libc library (called a 'crate' in Rust parlance) to provide the type definitions necessary to interface with C programs. As of the time of writing, this crate has had 95 releases. Contrast this with Ada’s Interfaces.C package, which was added the language in Ada 95 and hasn’t needed to change in any fundamental way since.
Rust's libc crate isn't third-party, it's first-party, developed by the Rust project itself: https://github.com/rust-lang/libc/ . It's also not just for "type definitions necessary to interface with C programs"; here's the first heading and first paragraph of its README:
"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).
The fact that this library contains low-level type definitions for every platform that Rust supports explains why it's had more than one release: new platforms get added, platforms add new interfaces, and platforms change the definitions of existing interfaces.
> It lacks basic features necessary for the task, like bitfields, and data structure packing.
The latter is achieved via the built-in `repr(packed)` attribute (https://doc.rust-lang.org/nomicon/other-reprs.html#reprpacke...) and the former is provided by the bitflags crate: https://crates.io/crates/bitflags (while unlike libc this does not live under the rust-lang org on Github, it does live under its own org which appears to be populated exclusively by Rust project team members).
-
Const-zero, a no_std crate* that acts like a const std::mem::zeroed()
It came up in this issue in the libc crate. The initializer for a static has to be const, which is why the issue submitter wanted it. He couldn't use lazy_static or once_cell, common patterns in Rust, since he was later using the static in a unix signal handler (which must be async signal safe).
rustix
-
OpenBSD 7.5 Released
It would be great for Rust to have a Linux target that doesn't use libc, but from what I've read, not many people are interested in this.
Found this as well: https://github.com/sunfishcode/mustang
Some discussion here: https://github.com/bytecodealliance/rustix/issues/76
-
Rust criticism from a Rustacean
Without actually having looked into this, how does https://github.com/bytecodealliance/rustix fit into points 1 & 2?
-
Cargo build in debug taking longer than in release?
I find this github issue: https://github.com/bytecodealliance/rustix/issues/575
-
Integrating rustix on NuttX
Hi Rust experts, we are willing to integrate rustix on NuttX RTOS, the initial effort was done by rustix author: https://github.com/bytecodealliance/rustix/tree/nuttx but it hit the wall since we don't know the right way to integrate cargo with the old-school NuttX's Makefiles. Any help or suggestion is welcome. More about NuttX here: https://nuttx.apache.org and here: https://nuttx.apache.org/docs/latest/
-
Pgwm 0.3 a pure rust `no_std` no libc window manager.
Have you considered using rustix? It provides many of the facilities of std without using libc.
- NVIDIA Security Team: "What if we just stopped using C?" (This is not about Rust)
-
Will Rust drop dependency on libc and make direct system calls? when ? (Please don't mention no_std case)
rustix can make syscalls directly to Linux. There's a rustc fork that can use it to build std.
-
Can rust be entirely written in rust and drop C usage in its code base ?
The rustix project claims to use raw syscalls (and vDSO calls) on linux and provides more memory / type safety compared to the libc API.
-
memmapix: A pure Rust library for cross-platform memory mapped IO, which replace libc with rustix.
Hi, the reason is explained by the description of https://github.com/bytecodealliance/rustix.
-
What crates would you add to a "batteries-included" library for Rust?
Please consider rustix as an alternative to nix.
What are some alternatives?
Klib - A standalone and lightweight C library
liblinux - Linux system calls.
ctl - My variant of the C Template Library
relibc - Mirror of https://gitlab.redox-os.org/redox-os/relibc
C-DataStructures-And-Algorithms - Generic data structures and algorithms implemented in c language.
clap-rs - A full featured, fast Command Line Argument Parser for Rust
mustang - Rust programs written entirely in Rust
compiler-builtins - Porting `compiler-rt` intrinsics to Rust
pottery - Pottery - A container and algorithm template library in C
cbindgen - A project for generating C bindings from Rust code
rust-brotli - Brotli compressor and decompressor written in rust that optionally avoids the stdlib