Docs/defensive-coding-guide
2
0
Fork 0
Code Issues 3 Pull requests 1 Projects Releases Packages Wiki Activity Actions

Update C-Allocators.xml - typos, title case

Browse source
This commit is contained in:
Mirek Jahoda 2017-10-23 14:49:13 +00:00
parent ab317f970c
commit c907ca6836
1 changed files with 11 additions and 11 deletions
Download patch file Download diff file Expand all files Collapse all files

22
en-US/C-Allocators.xml
View file

@ -2,10 +2,10 @@
<!DOCTYPE section PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
]>
<section id="sect-Defensive_Coding-C-Allocators">
<title>Memory allocators</title>
<title>Memory Allocators</title>
<section>
<title><function>malloc</function> and related functions</title>
<title><function>malloc</function> and Related Functions</title>
<para>
The C library interfaces for memory allocation are provided by
<function>malloc</function>, <function>free</function> and
@ -49,7 +49,7 @@
</para>
</section>
<section>
<title>Handling memory allocation errors</title>
<title>Handling Memory Allocation Errors</title>
<para>
Recovering from out-of-memory errors is often difficult or even
impossible. In these cases, <function>malloc</function> and
@ -71,8 +71,8 @@
</section>
<section id="sect-Defensive_Coding-C-Allocators-alloca">
<title><function>alloca</function> and other forms of stack-based
allocation</title>
<title><function>alloca</function> and Other Forms of Stack-based
Allocation</title>
<para>
Allocation on the stack is risky because stack overflow checking
is implicit. There is a guard page at the end of the memory
@ -96,7 +96,7 @@
if the allocated size is less than the page size (typically,
4096 bytes), but this case is relatively rare.) Additionally,
relying on <function>alloca</function> makes it more difficult
to reorgnize the code because it is not allowed to use the
to reorganize the code because it is not allowed to use the
pointer after the function calling <function>alloca</function>
has returned, even if this function has been inlined into its
caller.
@ -125,7 +125,7 @@
</section>
<section id="sect-Defensive_Coding-C-Allocators-Arrays">
<title>Array allocation</title>
<title>Array Allocation</title>
<para>
When allocating arrays, it is important to check for overflows.
The <function>calloc</function> function performs such checks.
@ -141,7 +141,7 @@
</section>
<section id="sect-Defensive_Coding-C-Allocators-Custom">
<title>Custom memory allocators</title>
<title>Custom Memory Allocators</title>
<para>
Custom memory allocates come in two forms: replacements for
<function>malloc</function>, and completely different interfaces
@ -173,7 +173,7 @@
<listitem>
<para>
It can be difficult to beat well-tuned general-purpose
allocators. In micro-benchmarks, pool allocators can show
allocators. In micro benchmarks, pool allocators can show
huge wins, and size-specific pools can reduce internal
fragmentation. But often, utilization of individual pools
is poor, and external fragmentation increases the overall
@ -184,7 +184,7 @@
</section>
<section>
<title>Conservative garbage collection</title>
<title>Conservative Garbage Collection</title>
<para>
Garbage collection can be an alternative to explicit memory
management using <function>malloc</function> and
@ -197,7 +197,7 @@
</para>
<para>
However, using a conservative garbage collector may reduce
opertunities for code reduce because once one library in a
opportunities for code reduce because once one library in a
program uses garbage collection, the whole process memory needs
to be subject to it, so that no pointers are missed. The
Boehm-Dehmers-Weiser collector also reserves certain signals for