Editing C standard library (section)

== Problems and workarounds ==

=== {{Anchor|BUFFER-OVERFLOW}}Buffer overflow vulnerabilities ===
Some functions in the C standard library have been notorious for having [[buffer overflow]] vulnerabilities and generally encouraging buggy programming ever since their adoption.<ref>{{cite web |url=https://www.techtarget.com/searchsecurity/definition/buffer-overflow |title=buffer overflow |last=Cobb |first=Michael |date=July 2021 |website=TechTarget |access-date=29 December 2024}}</ref>{{efn|[[Morris worm]] that takes advantage of the well-known vulnerability in <code>gets()</code> have been created as early as in 1988.}} The most criticized items are:
* [[C string handling|string-manipulation routines]], including <code>strcpy()</code> and <code>strcat()</code>, for lack of [[bounds checking]] and possible buffer overflows if the bounds are not checked manually;
* string routines in general, for [[side effect (computer science)|side-effects]], encouraging irresponsible buffer usage, not always guaranteeing valid [[null-terminated string|null-terminated]] output, linear length calculation;{{efn|in C standard library, string length calculation and looking for a string's end have [[Linear time|linear time complexities]] and are inefficient when used on the same or related strings repeatedly}}
* <code>[[printf]]()</code> family of routines, for spoiling the [[call stack|execution stack]] when the format string does not match the arguments given. This fundamental flaw created an entire class of attacks: [[format string attack]]s;
* <code>[[gets()|gets]]()</code> and <code>[[scanf]]()</code> family of I/O routines, for lack of (either any or easy) input length checking.

Except the extreme case with <code>gets()</code>, all the security vulnerabilities can be avoided by introducing auxiliary code to perform memory management, bounds checking, input checking, etc. This is often done in the form of wrappers that make standard library functions safer and easier to use. This dates back to as early as ''[[The Practice of Programming]]'' book by B. Kernighan and R. Pike where the authors commonly use wrappers that print error messages and quit the program if an error occurs.

The ISO C committee published Technical reports TR 24731-1<ref>{{cite web |url=http://www.open-std.org/JTC1/SC22/WG14/www/docs/n1225.pdf |title=ISO/IEC TR 24731-1: Extensions to the C Library, Part I: Bounds-checking interfaces |date=28 March 2007 |access-date=13 March 2014 |publisher=open-std.org }}</ref> and is working on TR 24731-2<ref>{{cite web |url=http://www.open-std.org/JTC1/SC22/WG14/www/docs/n1337.pdf |title=ISO/IEC WDTR 24731-2: Extensions to the C Library, Part II: Dynamic Allocation Functions |date=10 August 2008 |access-date=13 March 2014 |publisher=open-std.org }}</ref> to propose adoption of some functions with bounds checking and automatic buffer allocation, correspondingly. The former has met severe criticism with some praise,<ref>[https://stackoverflow.com/questions/372980/do-you-use-the-tr-24731-safe-functions-in-your-c-code Do you use the TR 24731 'safe' functions in your C code?] - Stack overflow</ref><ref>{{cite web |url=http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1106.txt |title=Austin Group Review of ISO/IEC WDTR 24731 |access-date=28 October 2011}}</ref> and the latter saw mixed response.

Despite concerns, TR 24731-1 was integrated into the C standards track in ISO/IEC 9899:2011 (C11), Annex K (''Bounds-checking interfaces''), and implemented approximately in Microsoft’s C/++ runtime (CRT) library for the Win32 and Win64 platforms.

(By default, Microsoft Visual Studio’s C and C++ compilers issue warnings when using older, "insecure" functions. However, Microsoft’s implementation of TR 24731-1 is subtly incompatible with both TR 24731-1 and Annex K,<ref>{{cite web |url=http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1967.htm#implementations |title=Field Experience With Annex K—''Bounds Checking Interfaces'' |access-date=9 October 2024}}</ref> so it’s common for portable projects to disable or ignore these warnings. They can be disabled directly by issuing <syntaxhighlight lang="c" copy class="nowrap"
  >#pragma warning(disable : 4996)</syntaxhighlight> before/around the call <nowiki>site[s]</nowiki> in question, or indirectly by issuing <syntaxhighlight lang="c" copy class="nowrap"
  >#define _CRT_SECURE_NO_WARNINGS 1</syntaxhighlight>
before including any headers.<ref>{{cite web |url=https://learn.microsoft.com/en-us/cpp/c-runtime-library/security-features-in-the-crt#eliminating-deprecation-warnings |title=Security Features in the CRT—Eliminating deprecation warnings |date=February 2023 |access-date=9 October 2024}}</ref> Command-line option <code>/D_CRT_NO_SECURE_WARNINGS=1</code> should have the same effect as this <code lang="c">#define</code>.)

=== Threading problems, vulnerability to race conditions ===
The <code>[[strerror]]()</code> routine is criticized for being [[thread safety|thread unsafe]] and otherwise vulnerable to [[race condition]]s.

=== Error handling ===
The error handling of the functions in the C standard library is not consistent and sometimes confusing. According to the Linux manual page <code>math_error</code>, "The current (version 2.8) situation under glibc is messy. Most (but not all) functions raise exceptions on errors. Some also set ''errno''. A few functions set ''errno'', but do not raise an exception. A very few functions do neither."<ref>{{cite web |url=http://man7.org/linux/man-pages/man7/math_error.7.html |title=math_error - detecting errors from mathematical functions |date=11 August 2008 |access-date=13 March 2014 |website=man7.org}}</ref>