Does their ToS give them additional rights to the code uploaded to GitHub? There are several unofficial copies of projects like glibc [1] uploaded by people who definitely do not have the authority to grant any additional rights to the code.
[1]: https://github.com/bminor/glibc
In Microsoft forked MIT licensed repo and changed the copyright [fixed]bminor
glibc
C2015–2026
bminor / glibc · Archived
glibc
Unofficial mirror of sourceware glibc repository.
42Distinct people
45Mentions
0Explicit recommenders
1.9KGitHub stars
What to know before exploring
What it is
Unofficial mirror of sourceware glibc repository.
GitHub
Where it is used
No documented product use was verified in the last source check.
What people are saying
No recommendation phrase was found in the indexed comments.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
No other repository is repeatedly linked in the same discussions.
This week on Hacker News
Nov 8–Nov 15 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/15/2026, 10:49:33 PM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year45 dated mentions
Observed mentions: 2015-09-26 00:35:59 UTC to 2026-08-20 04:08:08 UTC.
* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2015 | 2015-01-01 00:00:00 UTC | 2016-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2016 | 2016-01-01 00:00:00 UTC | 2017-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2017 | 2017-01-01 00:00:00 UTC | 2018-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 3 | 0 | 3 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 4 | 0 | 4 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 10 | 0 | 10 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 7 | 0 | 7 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 8 | 0 | 8 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 3 | 0 | 3 |
| 2025 | 2025-01-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 6 | 0 | 6 |
| 2026 (partial) | 2026-01-01 00:00:00 UTC | 2027-01-01 00:00:00 UTC | 1 | 0 | 1 |
From the project README
An excerpt from the repository, fetched Nov 13, 2026.
Read the project’s introduction
This directory contains the sources of the GNU C Library.
See the file "version.h" for what release version you have.
The GNU C Library is the standard system C library for all GNU systems,
and is an important part of what makes up a GNU system. It provides the
system API for all programs written in C and C-compatible languages such
as C++ and Objective C; the runtime facilities of other programming
languages use the C library to access the underlying operating system.
In GNU/Linux systems, the C library works with the Linux kernel to
implement the operating system behavior seen by user applications.
In GNU/Hurd systems, it works with a microkernel and Hurd servers.
The GNU C Library implements much of the POSIX.1 functionality in the
GNU/Hurd system, using configurations i[4567]86-*-gnu and x86_64-gnu.
When working with Linux kernels, this version of the GNU C Library
requires Linux kernel version 3.2 or later.
Also note that the shared version of the libgcc_s library must be
installed for the pthread library to work correctly.
The GNU C Library supports these configurations for using Linux kernels:
aarch64*-*-linux-gnu
alpha*-*-linux-gnu
arc*-*-linux-gnu
arm-*-linux-gnueabi
csky-*-linux-gnuabiv2
hppa-*-linux-gnu
i[4567]86-*-linux-gnu
x86_64-*-linux-gnu Can build either x86_64 or x32
loongarch64-*-linux-gnu Hardware floating point, LE only.
m68k-*-linux-gnu
microblaze*-*-linux-gnu
mips-*-linux-gnu
mips64-*-linux-gnu
or1k-*-linux-gnu
powerpc-*-linux-gnu Hardware or software floating point, BE only.
powerpc64*-*-linux-gnu Big-endian and little-endian.
s390-*-linux-gnu
s390x-*-linux-gnu
riscv32-*-linux-gnu
riscv64-*-linux-gnu
sh[34]-*-linux-gnu
sparc*-*-linux-gnu
sparc64*-*-linux-gnu
If you are interested in doing a port, please contact the glibc
maintainers; see https://www.gnu.org/software/libc/ for more
information.
See the file INSTALL to find out how to configure, build, and install
the GNU C Library. You might also consider reading the WWW pages for
the C library at https://www.gnu.org/software/libc/.
The GNU C Library is (almost) completely documented by the Texinfo manual
found in the `manual/' subdirectory. The manual is still being updated
and contains some known errors and omissions; we regret that we do not
have the resources to work on the manual as much as we would like. For
corrections to the manual, please file a bug in the `manual' component,
following the bug-reporting instructions below. Please be sure to check
the manual in the current development sources to see if your problem has
already been corrected.
Please see https://www.gnu.org/software/libc/bugs.html for bug reporting
information. We are now using the Bugzilla system to track all bug reports.
This web page gives detailed information on how to report bugs properly.
The GNU C Library is free software. See the file COPYING.LIB for copying
conditions, and LICENSES for notices about a few contributions that require
these additional notices to be distributed. License copyright years may be
listed using range notation, e.g., 1996-2015, indicating that every year in
the range, inclusive, is a copyrightable year that would otherwise be listed
individually.
Read the full README on GitHubWhat Hacker News says
10 sourcesNow compare how many different versions of the functions are required for the dozens of possible x86 extensions (and combinations of them) and all the prologue/epilogue code required to watch out for page boundaries and unaligned pointers and as well as the length of the inner loop to handle all the packing/unpacking and cobbeling together horizontal operations to the required masks and turn somehow use them for flow control where needed. It's enough code to put painful pressure on the instruction cache and requires wide OoO superscalar CPU cores to be worth the overhead compare the code in the RISC V vector spec with this strcmp https://github.com/bminor/glibc/blob/master/sysdeps/x86_64/m... and tell me it's a clean and straightforward implementation using the instruction set as intended and not an ugly hack around its limitations.
In RISC-V Int. Ratifies 15 New Specs, Opening Up New RISC-V Design PossibilitiesGiven the number of implementations of str* routines in https://github.com/bminor/glibc/tree/master/sysdeps/x86_64/m..., maybe you might want to revisit your last statement. PCMP/MOVMSK work well enough for finding the trailing NUL.
In RISC-V Int. Ratifies 15 New Specs, Opening Up New RISC-V Design PossibilitiesThe glibc/musl select library call doesn't verify nfds is < FD_SETSIZE so you could create your own fd_set as large as you want it.
glibc: https://github.com/bminor/glibc/blob/master/sysdeps/unix/sys...
musl: https://git.musl-libc.org/cgit/musl/tree/src/select/select.c
*BSD allows you to define your own FD_SETSIZE before including system headers.
In File Descriptor LimitsIf you read the man page bugs section: https://man7.org/linux/man-pages/man2/select.2.html
"The Linux kernel imposes no fixed limit, but the glibc implementation makes fd_set a fixed-size type, with FD_SETSIZE defined as 1024"
Everyone using select, with very few exceptions, is using glibc.
That limitation does appear to exist in glibc if you look at the source code. The source code requires you to pass a glibc defined 'fd_set' type https://man7.org/linux/man-pages/man2/select.2.html
That struct is defined here: https://github.com/bminor/glibc/blob/595c22ecd8e87a27fd19270...
It does seem to have the limits described by the blogpost.
In File Descriptor Limitshere is the present source code for glibc where faccessat2 is used. What you say is true for some cases; if glibc is built for kernel versions below 0x050800 then it doesn't assume faccessat2, here it falls back to faccessat for some cases - and faccessat was added in 2.6.16.
But if you have flags other than AT_SYMLINK_NOFOLLOW or AT_EACCESS the call just fails without doing the fallback. See https://github.com/bminor/glibc/blob/595c22ecd8e87a27fd19270...
TIL that this this glibc mirror is kept in sync with the real one https://github.com/bminor/glibc
In Linux and Glibc API ChangesI am confused about this comment. The parent comment gave clear call stack that pointing to the problem where the glibc's sscanf implementation would strlen the input string no matter what format string you use (because it need to masquerade as a file and that requires strlen the whole input: https://github.com/bminor/glibc/blob/21c3f4b5368686ade28d90d...)
All your magic on format string doesn't change that poor behavior unless you manually add '\0' somewhere to null-terminate the input string early.
If you parse the year-month-day in 100 places of that input string, it will strlen 100 times. And now replace the "100 places" to a linear function of the input string length (strlen(input) / 11?), that is quadratic.
In Parsing can become accidentally quadratic because of sscanfSeen the GTA post already and the sscanf behavior is very surprising as one would expect it to parse the given string until the given format is satisfied or \0 is hit. Seems like this is not the case. Found this: https://stackoverflow.com/a/23924112
> sscanf() converts the string you pass in to an _IO_FILE* to make the string look like a "file". This is so the same internal _IO_vfscanf() can be used for both a string and a FILE*. However, as part of that conversion, done in a _IO_str_init_static_internal() function, it calls __rawmemchr (ptr, '\0'); essentially a strlen() call, on your input string.
Looks correct. Call flow:
https://github.com/bminor/glibc/blob/21c3f4b5368686ade28d90d...
https://github.com/bminor/glibc/blob/21c3f4b5368686ade28d90d...
https://github.com/bminor/glibc/blob/21c3f4b5368686ade28d90d...
https://github.com/bminor
Read the rest
I think that the author hasn't checked them all. Even this isn't checking them all.
The MUSL C library' sscanf() does not do this, but does call memchr() on limited substrings of the input string as it refills its input buffer, so it's not entirely free of this behaviour.
* https://git.musl-libc.org/cgit/musl/tree/src/stdio/vsscanf.c
The sscanf() in Microsoft's C library does this because it all passes through a __stdio_common_vsscanf() function which uses length-counted rather than NUL-terminated strings internally.
* https://github.com/tpn/winsdk-10/blob/master/Include/10.0.16...
* https://github.com/huangqinjin/ucrt/blob/master/inc/corecrt_...
The GNU C library does something similar, using a FILE structure alongside a special "operations" table, with a _rawmemchr() in the initialization.
* https://github.com/bminor/glibc/blob/master/
Read the rest
libio/strops.c#L...
* https://github.com/bminor/glibc/blob/master/libio/strfile.h#...
The FreeBSD C library does not use a separate "operations" table.
* https://github.com/freebsd/freebsd-src/blob/main/lib/libc/st...
A glib summary is that sscanf() in these implementations has to set up state on every call that fscanf() has the luxury of keeping around over multiple calls in the FILE structure. They're setting up special nonce FILE objects for each sscanf() call, and that involves finding out how long the input string is every time.
It is food for thought. How much could life be improved if these implementations exported the way to set up these nonce FILE structures from a string, and callers used fscanf() instead of sscanf()? How many applications are scanning long strings with lots of calls to sscanf()?
Geez man, way to take things out of context. Let me fix your quote:
> Going through the libc is very unlikely to actually introduce vulnerabilities, especially if going through the lowest level function that directly wrap the syscall.
Sure, glibc has a bunch of bugs. But the lowest level of functions, that just wrap the syscalls, are very unlikely to have bugs. Here's the `read` implementation, for instance:
https://github.com/bminor/glibc/blob/21c3f4b5368686ade28d90d...
All it does is delegate to the low-level syscall, with some extra handling around to handle async calls (which can be removed when compiling glibc yourself, but you're probably not doing this).
Here's clone:
https://github.com/bminor/glibc/blob/21c3f4b5368686ade28d90d...
This one's written in asm, and you can't really simplify it all that much more.
All the functions that
Read the rest
wrap the low-level syscalls are very hard to get wrong, really. Where the glibc bugs come from are the high-level functions, like pthread. But those can trivially be bypassed if necessary.