| Libc | Libc | |
|---|---|---|
| 4 | 2 | |
| 6 | 45 | |
| - | - | |
| 0.0 | 2.9 | |
| about 4 years ago | about 1 month ago | |
| C | C | |
| GNU General Public License v3.0 or later | 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
-
Setenv Is Not Thread Safe and C Doesn't Want to Fix It
[3] https://github.com/apple-open-source-mirror/Libc/blob/master...
-
Getaddrinfo() on glibc calls getenv(), oh boy
Doesn't musl have the same issue? https://github.com/JuliaLang/julia/issues/34726#issuecomment...
I also wonder about OSX's libc. Newer versions seem to have some sort of locking https://github.com/apple-open-source-mirror/Libc/blob/master...
but older versions (from 10.9) don't have any lockign: https://github.com/apple-oss-distributions/Libc/blob/Libc-99...
- Regex and gcc versions
-
Null
All three are probably using glibc, which does that, yes. On Darwin Apple’s libc prints “(null)”: https://github.com/apple-open-source-mirror/Libc/blob/5e566b.... I should also note that passing a non-null pointer to printf is the only correct way to use it ;)
Libc
-
Setenv Is Not Thread Safe and C Doesn't Want to Fix It
Does rust also add an pthread_atfork handler? Otherwise, it seems likely still unsafe for rust to claim to support calling fork (for execv) or posix_spawn, as most libc call realloc on the `environ` contents, but do not appear to take any care to ensure that (v)fork/posix_spawn doesn't happen concurrently with that. Worse yet, the `posix_spawnp` API takes an `envp` parameter and expects you to pass it the global pointer `environ`, which is completely unsynchronized across that fork call. It is not obvious to me that this is a security gap, but certainly it seems to me that this would violate rust's safety claim, if it is not taking added precautions there.
The Apple Libc appears to just unconditionally drops the environ lock in the child (https://github.com/apple-oss-distributions/Libc/blob/c5a3293...), while glibc doesn't appear to even bother with that (https://github.com/bminor/glibc/blob/6ae7b5f43d4b13f24606d71...)
-
Getaddrinfo() on glibc calls getenv(), oh boy
Doesn't musl have the same issue? https://github.com/JuliaLang/julia/issues/34726#issuecomment...
I also wonder about OSX's libc. Newer versions seem to have some sort of locking https://github.com/apple-open-source-mirror/Libc/blob/master...
but older versions (from 10.9) don't have any lockign: https://github.com/apple-oss-distributions/Libc/blob/Libc-99...
What are some alternatives?
musl - unofficial musl mirror git://git.musl-libc.org/musl
systemd - The systemd System and Service Manager
htshells - Self contained htaccess shells and attacks
illumos-gate - An open-source Unix operating system
go - The Go programming language
rust - Empowering everyone to build reliable and efficient software.
big-list-of-naughty-strings - The Big List of Naughty Strings is a list of strings which have a high probability of causing issues when used as user-input data.
chrono - Date and time library for Rust
src - Automatic conversion of the NetBSD src CVS module, use with care. Please submit bugs/changes via https://gnats.netbsd.org
time - The most used Rust library for date and time handling.
glibc - Unofficial mirror of sourceware glibc repository. Updated daily.
julia - The Julia Programming Language