Editing C dynamic memory allocation (section)

==Common errors==
The improper use of dynamic memory allocation can frequently be a source of bugs. These can include security bugs or program crashes, most often due to [[segmentation fault]]s.

Most common errors are as follows:<ref>{{Cite book|title=Pointers on C|last=Reek|first=Kenneth|date=1997-08-04|publisher=Pearson|isbn=9780673999863|edition=1|language=en}}</ref>
;Not checking for allocation failures: Memory allocation is not guaranteed to succeed, and may instead return a null pointer. Using the returned value, without checking if the allocation is successful, invokes [[undefined behavior]]. This usually leads to crash (due to the resulting segmentation fault on the null pointer dereference), but there is no guarantee that a crash will happen so relying on that can also lead to problems.
;Memory leaks: Failure to deallocate memory using <code>free</code> leads to buildup of non-reusable memory, which is no longer used by the program. This wastes memory resources and can lead to allocation failures when these resources are exhausted. {{anchor|Use after free}}
;Logical errors: All allocations must follow the same pattern: allocation using <code>malloc</code>, usage to store data, deallocation using <code>free</code>. Failures to adhere to this pattern, such as memory usage after a call to <code>free</code> ([[dangling pointer]]) or before a call to <code>malloc</code> ([[wild pointer]]), calling <code>free</code> twice ("double free"), etc., usually causes a segmentation fault and results in a crash of the program. These errors can be transient and hard to debug – for example, freed memory is usually not immediately reclaimed by the OS, and thus dangling pointers may persist for a while and appear to work.

In addition, as an interface that precedes ANSI C standardization, {{code|malloc}} and its associated functions have behaviors that were intentionally left to the implementation to define for themselves. One of them is the zero-length allocation, which is more of a problem with {{code|realloc}} since it is more common to resize to zero.<ref>{{cite web |title=MEM04-C. Beware of zero-length allocations - SEI CERT C Coding Standard - Confluence |url=https://wiki.sei.cmu.edu/confluence/display/c/MEM04-C.+Beware+of+zero-length+allocations |website=wiki.sei.cmu.edu}}<!-- Note: the example is bullshit. Freeing NULL is safe because it does nothing. --></ref> Although both [[POSIX]] and the [[Single Unix Specification]] require proper handling of 0-size allocations by either returning {{code|NULL}} or something else that can be safely freed,<ref>{{cite web |title=POSIX.1-2017: malloc |url=https://pubs.opengroup.org/onlinepubs/9699919799/ |website=pubs.opengroup.org |access-date=29 November 2019}}</ref> not all platforms are required to abide by these rules. Among the many double-free errors that it has led to, the 2019 [[WhatsApp]] RCE was especially prominent.<ref>{{cite web |last1=Awakened |title=How a double-free bug in WhatsApp turns to RCE |date=2 October 2019 |url=https://awakened1712.github.io/hacking/hacking-whatsapp-gif-rce/ |access-date=29 November 2019}}</ref> A way to wrap these functions to make them safer is by simply checking for 0-size allocations and turning them into those of size 1. (Returning {{code|NULL}} has its own problems: it otherwise indicates an out-of-memory failure. In the case of {{code|realloc}} it would have signaled that the original memory was not moved and freed, which again is not the case for size 0, leading to the double-free.)<ref>{{cite tweet |last1=Felker |first1=Rich |title=Wow. The WhatsApp RCE was the wrong behavior for realloc(p,0) so many implementations insist on. |user=RichFelker |number=1179701167569416192 |access-date=6 August 2022 |date=3 October 2019}}</ref>