From 6f40b81eb07247aa4d6336bf25b18a831649bc8b Mon Sep 17 00:00:00 2001
From: Mirek Jahoda <mjahoda@redhat.com>
Date: Mon, 23 Oct 2017 14:42:25 +0000
Subject: [PATCH] Update C-Language.xml - Title Case

---
 en-US/C-Language.xml | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/en-US/C-Language.xml b/en-US/C-Language.xml
index 8f6f74d..12b0845 100644
--- a/en-US/C-Language.xml
+++ b/en-US/C-Language.xml
@@ -2,14 +2,14 @@
 <!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-Language">
-  <title>The core language</title>
+  <title>The Core Language</title>
   <para>
     C provides no memory safety.  Most recommendations in this section
     deal with this aspect of the language.
   </para>
 
   <section id="sect-Defensive_Coding-C-Undefined">
-    <title>Undefined behavior</title>
+    <title>Undefined Behavior</title>
     <para>
       Some C constructs are defined to be undefined by the C standard.
       This does not only mean that the standard does not describe
@@ -32,7 +32,7 @@
   </section>
 
   <section id="sect-Defensive_Coding-C-Pointers">
-    <title>Recommendations for pointers and array handling</title>
+    <title>Recommendations for Pointers and Array Handling</title>
     <para>
       Always keep track of the size of the array you are working with.
       Often, code is more obviously correct when you keep a pointer
@@ -75,7 +75,7 @@
   </section>
 
   <section id="sect-Defensive_Coding-C-Arithmetic">
-    <title>Recommendations for integer arithmetic</title>
+    <title>Recommendations for Integer Arithmetic</title>
     <para>
       Overflow in signed integer arithmetic is undefined.  This means
       that it is not possible to check for overflow after it happened,
@@ -174,7 +174,7 @@
   </section>
 
   <section id="sect-Defensive_Coding-C-Globals">
-    <title>Global variables</title>
+    <title>Global Variables</title>
     <para>
       Global variables should be avoided because they usually lead to
       thread safety hazards.  In any case, they should be declared