HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
lattera
glibc
C2015–2026
lattera / glibc · Archived

glibc

GNU Libc - Extremely old repo used for research purposes years ago. Please do not rely on this repo.

Explore on GitHubRead Hacker News discussions
27Distinct people
27Mentions
1Explicit recommenders
2KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

GNU Libc - Extremely old repo used for research purposes years ago. Please do not rely on this repo.

GitHub

Where it is used

No documented product use was verified in the last source check.

What people are saying

If I may add my two cents... I highly recommend reading through the standard library and then looking at how they are implemented in actual C. The string library is probably…

s_m_t used a recommendation phrase. One indexed comment matches. This is a phrase match, not a verdict.

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, 9:28:18 AM 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 year27 dated mentions

Observed mentions: 2015-02-12 10:32:11 UTC to 2026-03-12 22:02:01 UTC.

0123452015-01-01 00:00:00 UTC to 2016-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments20152016-01-01 00:00:00 UTC to 2017-01-01 00:00:00 UTC (exclusive): 3 mentions; 0 submissions, 3 comments2017-01-01 00:00:00 UTC to 2018-01-01 00:00:00 UTC (exclusive): 5 mentions; 0 submissions, 5 comments2018-01-01 00:00:00 UTC to 2019-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments2019-01-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments2020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments20202021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 4 mentions; 0 submissions, 4 comments2022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 4 mentions; 1 submissions, 3 comments2024-01-01 00:00:00 UTC to 2025-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2025-01-01 00:00:00 UTC to 2026-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments2026-01-01 00:00:00 UTC to 2027-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments. Incomplete calendar period.2026*

* 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
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20152015-01-01 00:00:00 UTC2016-01-01 00:00:00 UTC101
20162016-01-01 00:00:00 UTC2017-01-01 00:00:00 UTC303
20172017-01-01 00:00:00 UTC2018-01-01 00:00:00 UTC505
20182018-01-01 00:00:00 UTC2019-01-01 00:00:00 UTC202
20192019-01-01 00:00:00 UTC2020-01-01 00:00:00 UTC202
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC101
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC404
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC101
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC413
20242024-01-01 00:00:00 UTC2025-01-01 00:00:00 UTC101
20252025-01-01 00:00:00 UTC2026-01-01 00:00:00 UTC202
2026 (partial)2026-01-01 00:00:00 UTC2027-01-01 00:00:00 UTC101

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. 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 arm-*-linux-gnueabi hppa-*-linux-gnu i[4567]86-*-linux-gnu x86_64-*-linux-gnu Can build either x86_64 or x32 ia64-*-linux-gnu m68k-*-linux-gnu microblaze*-*-linux-gnu mips-*-linux-gnu mips64-*-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 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 http://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 http://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 http://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 GitHub

What Hacker News says

3 sources
gens·Oct 15, 2016
Does anybody have an example of good performance of unaligned memory access on modern cpus ? And note that it doesn't matter if the cpu supports AVX, but if it has a flag that says it can do fast unaligned memory access (i don't remember, is it misalignsse ?). Common sense says that unaligned access can't be faster then aligned. And if you have data that fits into a ymm register, then you might as well use aligned access (a neural network is usually an example of such). I did test it a while ago. Problem is that i don't remember if it was on this, modern, cpu or the older one. I could test if i cared enough for other peoples opinion, but alas i don't (only usage of unaligned AVX access i found to be from newbies to SIMD). An example, that you request, would be to look at glibc memcpy, that uses ssse3 [0] so that it could always get aligne
Read the rest
d access (ssse3 has per-byte operations). In other words, how about that the people who claim that operations that do extra work are as fast as the ones that don't prove it ? Instead of the burden of proof falling on people that don't have such an opinion/experience ? Then i will bow my head and say "You are right. Thank you for pointing that out". But alas google-ing for 10min and have found no such benchmark anywhere. And writing such a test isn't hard, not in the slightest. [0]https://github.com/lattera/glibc/blob/master/sysdeps/x86_64/...
In Intel will add deep-learning instructions to its processors
DannyBee·May 13, 2016
Complaining about microbenchmark performance, then perf benchmarking in a completely unscientific way, is pretty bad (These are non-quiesced machines, etc) The error bars show it's probably slower, but i'm pretty sure he's not going to get valid measurements to 0.002s by running it once with time without doing things like disabling CPU throttling, etc :) Of course, looking at julia's microbenchmark for C, they had to do a bunch of things to get the compilers to stop optimizing away their benchmarks, so that should tell you something right there :) The example they give of sprintf calls is completely misleading, since sprintf_chk is going to be several hundred instructions itself. Follow https://github.com/lattera/glibc/blob/master/debug/sprintf_c... all the way down the rabbit hole :)
In Giving up on Julia
pcwalton·Feb 17, 2016
> ALL of these buffer overflows in C happen because the C stack grows backward, and old space is after new space. This isn't true, as pointed out elsewhere in the thread. In fact, it even looks likely that this specific bug is still exploitable under your proposal. Here is the bug: https://github.com/lattera/glibc/blob/a2f34833b1042d5d8eeb26... The buffer overflow occurs here: https://github.com/lattera/glibc/blob/a2f34833b1042d5d8eeb26... Notice that the buffer overflow occurs not in __libc_res_nquery itself but in one of the functions it calls, send_dg. From a quick glance it looks like the call chain is __libc_res_nquery -> __libc_res_nsend -> send_dg. Because the buffer is alloca'd in __libc_res_nquery but overwritten in a later call frame, an attacker should be able to overwrite either the return address of send_dg or __libc_res_nsen
Read the rest
d even if stacks grow the other way. So your proposed fix doesn't address this issue.
In Glibc getaddrinfo stack-based buffer overflow

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.