Editing Glibc (section)

==Functionality==
glibc provides the functionality required by the [[Single UNIX Specification]], [[POSIX]] (1c, 1d, and 1j) and some of the functionality required by [[International Organization for Standardization|ISO]] [[C11 (C standard revision)|C11]], [[International Organization for Standardization|ISO]] [[C99]], [[Berkeley Unix]] (BSD) interfaces, the [[System V Interface Definition]] (SVID) and the [[X/Open Portability Guide]] (XPG), Issue 4.2, with all extensions common to XSI ([[X/Open System Interface]]) compliant systems along with all X/Open UNIX extensions.

In addition, glibc also provides extensions that have been deemed useful or necessary while developing [[GNU]].

===Supported hardware and kernels===
glibc is used in systems that run many different [[kernel (operating system)|kernels]] and different [[Computer hardware|hardware]] architectures. Its most common use is in systems using the [[Linux kernel]] on [[x86]] hardware, however, officially supported hardware<ref>{{cite web | url = https://sourceware.org/glibc/wiki/MAINTAINERS#Machine_maintainers | title = The GNU C Library machine maintainers. | access-date = 8 October 2015 | archive-date = 18 April 2016 | archive-url = https://web.archive.org/web/20160418170046/https://sourceware.org/glibc/wiki/MAINTAINERS#Machine_maintainers | url-status = live }}</ref> includes: [[ARM architecture|ARM]], [[ARC (processor)|ARC]], [[C-SKY]], [[DEC Alpha]], [[IA-64]], [[Motorola 68000 series|Motorola m68k]], [[MicroBlaze]], [[MIPS architecture|MIPS]], [[Nios II]], [[PA-RISC]]<!--"hppa"-->, [[PowerPC]], [[RISC-V]], [[IBM System z|s390]], [[SPARC]], and [[x86]] (old versions support [[TILE64|TILE]]). It officially supports the [[GNU Hurd|Hurd]] and [[Linux kernel|Linux]] kernels. Additionally, there are heavily patched versions that run on the kernels of [[FreeBSD]] and [[NetBSD]] (from which [[Debian gnu/kfreebsd|Debian GNU/kFreeBSD]] and [[Debian GNU/NetBSD]] systems are built, respectively), as well as a forked-version of [[OpenSolaris]].<ref>{{cite web|url=https://csclub.uwaterloo.ca/~dtbartle/opensolaris/|title=GNU/kOpenSolaris (GNU libc/base + OpenSolaris kernel)|last1=Bartley|first1=David|last2=Spang|first2=Michael|access-date=2008-12-16|archive-date=6 November 2019|archive-url=https://web.archive.org/web/20191106181358/http://csclub.uwaterloo.ca/~dtbartle/opensolaris/|url-status=dead}}</ref> It is also used (in an edited form) and named {{mono|libroot.so}} in [[BeOS]] and [[Haiku (operating system)|Haiku]].<ref>{{cite web
 | url = https://github.com/haiku/haiku/tree/master/src/system/libroot
 | title = Haiku Source
 | website = [[GitHub]]
 | quote = libroot.so is not part of GNU project and is included in Haiku source code.
 | access-date = 15 October 2014
 | archive-date = 1 May 2016
 | archive-url = https://web.archive.org/web/20160501130749/https://github.com/haiku/haiku/tree/master/src/system/libroot
 | url-status = live
 }}</ref>

===Use in small devices===
glibc has been criticized as being "[[Software bloat|bloated]]" and slower than other libraries in the past, e.g. by [[Linus Torvalds]]<ref>{{cite web|last=Torvalds|first=Linus|url=http://ecos.sourceware.org/ml/libc-alpha/2002-01/msg00079.html|title=Posting to the glibc mailing list|date=9 January 2002<!-- 19:02:37-->|access-date=22 July 2007|archive-date=12 October 2015|archive-url=https://web.archive.org/web/20151012215444/http://ecos.sourceware.org/ml/libc-alpha/2002-01/msg00079.html|url-status=live}}</ref> and [[embedded Linux]] programmers. For this reason, several [[C standard library#Implementations|alternative C standard libraries]] have been created which emphasize a smaller footprint. However, many small-device projects use GNU libc over the smaller alternatives because of its application support, standards compliance, and completeness. Examples include [[Openmoko]]<ref>{{cite web
 | url   = http://wiki.openmoko.org/wiki/OpenMoko
 | title   = OpenMoko components
 | quote   = We will use glibc (not uClibC) ... The alternatives may save more space and be more optimized, but are more likely to give us integration headaches
 | access-date   = 13 May 2008
 | archive-date   = 22 April 2016
 | archive-url   = https://web.archive.org/web/20160422073925/http://wiki.openmoko.org/wiki/Openmoko
 | url-status   = live
 }}</ref> and [[Familiar Linux]] for iPaq handhelds (when using the [[GPE Palmtop Environment|GPE]] display software).<ref>{{cite web
 | url   = https://marc.info/?l=familiar&m=118666899424374&w=2
 | title   = Re: [Familiar] Which glibc for Familiar 0.8.4&nbsp;&nbsp;?
 | quote   = Question: which version of the GLIBC was used to build the Familiar 0.8.4 ? Answer: 2.3.3
 | access-date   = 26 November 2018
 | archive-date   = 12 March 2022
 | archive-url   = https://web.archive.org/web/20220312062719/https://marc.info/?l=familiar&m=118666899424374&w=2
 | url-status   = live
 }}</ref>

=== Secure string functions ===
glibc does not implement bounds-checking interfaces defined in [[C11 (C standard revision)|C11]] and did not implement strlcpy and strlcat<ref>{{Cite web |last=Kerrisk |first=Michael |title=The ups and downs of strlcpy() |url=https://lwn.net/Articles/507319/ |access-date=2023-12-09 |website=[[LWN.net]] |archive-date=9 December 2023 |archive-url=https://web.archive.org/web/20231209152233/https://lwn.net/Articles/507319/ |url-status=live }}</ref><ref>{{Cite web |last=Corbet |first=Jonathan |title=Adding strlcpy() to glibc |url=https://lwn.net/Articles/612244/ |access-date=2023-12-09 |website=[[LWN.net]] |archive-date=9 December 2023 |archive-url=https://web.archive.org/web/20231209152233/https://lwn.net/Articles/612244/ |url-status=live }}</ref> until 2023 on the grounds that "in practice these functions can cause trouble, as their intended use encourages silent data truncation, adds complexity and inefficiency, and does not prevent all buffer overruns in the destinations."<ref name=":2">{{Cite web |title=FAQ |url=https://sourceware.org/glibc/wiki/FAQ#Why_no_strlcpy_.2F_strlcat.3F |access-date=2023-12-09 |website=sourceware.org |archive-date=9 December 2023 |archive-url=https://web.archive.org/web/20231209151431/https://sourceware.org/glibc/wiki/FAQ#Why_no_strlcpy_.2F_strlcat.3F |url-status=live }}</ref> The FAQ pointed out that the bounds-checking interfaces were optional in the ISO standard and that snprintf was available as an alternative.<ref name=":2" />