<?xml version='1.0' encoding='utf-8' ?>
<!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-CXX-Language">
  <title>The core language</title>
  <para>
    C++ includes a large subset of the C language.  As far as the C
    subset is used, the recommendations in <xref
    linkend="chap-Defensive_Coding-C"/> apply.
  </para>

  <section>
    <title>Array allocation with <literal>operator new[]</literal></title>
    <para>
      For very large values of <literal>n</literal>, an expression
      like <literal>new T[n]</literal> can return a pointer to a heap
      region which is too small.  In other words, not all array
      elements are actually backed with heap memory reserved to the
      array.  Current GCC versions generate code that performs a
      computation of the form <literal>sizeof(T) * size_t(n) +
      cookie_size</literal>, where <literal>cookie_size</literal> is
      currently at most 8.  This computation can overflow, and
      GCC-generated code does not detect this.
    </para>
    <para>
      The <literal>std::vector</literal> template can be used instead
      an explicit array allocation.  (The GCC implementation detects
      overflow internally.)
    </para>
    <para>
      If there is no alternative to <literal>operator new[]</literal>,
      code which allocates arrays with a variable length must check
      for overflow manually.  For the <literal>new T[n]</literal>
      example, the size check could be <literal>n || (n > 0 &amp;&amp;
      n &gt; (size_t(-1) - 8) / sizeof(T))</literal>.  (See <xref
      linkend="sect-Defensive_Coding-C-Arithmetic"/>.)  If there are
      additional dimensions (which must be constants according to the
      C++ standard), these should be included as factors in the
      divisor.
    </para>
    <para>
      These countermeasures prevent out-of-bounds writes and potential
      code execution.  Very large memory allocations can still lead to
      a denial of service.  <xref
      linkend="sect-Defensive_Coding-Tasks-Serialization-Decoders"/>
      contains suggestions for mitigating this problem when processing
      untrusted data.
    </para>
    <para>
      See <xref linkend="sect-Defensive_Coding-C-Allocators-Arrays"/>
      for array allocation advice for C-style memory allocation.
    </para>
  </section>

  <section>
    <title>Overloading</title>
    <para>
      Do not overload functions with versions that have different
      security characteristics.  For instance, do not implement a
      function <function>strcat</function> which works on
      <type>std::string</type> arguments.  Similarly, do not name
      methods after such functions.
    </para>
  </section>
  <section>
    <title>ABI compatibility and preparing for security updates</title>
    <para>
      A stable binary interface (ABI) is vastly preferred for security
      updates.  Without a stable ABI, all reverse dependencies need
      recompiling, which can be a lot of work and could even be
      impossible in some cases.  Ideally, a security update only
      updates a single dynamic shared object, and is picked up
      automatically after restarting affected processes.
    </para>
    <para>
      Outside of extremely performance-critical code, you should
      ensure that a wide range of changes is possible without breaking
      ABI.  Some very basic guidelines are:
    </para>
    <itemizedlist>
      <listitem>
	<para>
	  Avoid inline functions.
	</para>
      </listitem>
      <listitem>
	<para>
	  Use the pointer-to-implementation idiom.
	</para>
      </listitem>
      <listitem>
	<para>
	  Try to avoid templates.  Use them if the increased type
	  safety provides a benefit to the programmer.
	</para>
      </listitem>
      <listitem>
	<para>
	  Move security-critical code out of templated code, so that
	  it can be patched in a central place if necessary.
	</para>
      </listitem>
    </itemizedlist>
    <para>
      The KDE project publishes a document with more extensive
      guidelines on ABI-preserving changes to C++ code, <ulink
      url="http://techbase.kde.org/Policies/Binary_Compatibility_Issues_With_C++">Policies/Binary
      Compatibility Issues With C++</ulink>
      (<emphasis>d-pointer</emphasis> refers to the
      pointer-to-implementation idiom).
    </para>
  </section>

  <section id="sect-Defensive_Coding-CXX-Language-CXX11">
    <title>C++0X and C++11 support</title>
    <para>
      GCC offers different language compatibility modes:
    </para>
    <itemizedlist>
      <listitem>
	<para>
	  <option>-std=c++98</option> for the original 1998 C++
	  standard
	</para>
      </listitem>
      <listitem>
	<para>
	  <option>-std=c++03</option> for the 1998 standard with the
	  changes from the TR1 technical report
	</para>
      </listitem>
      <listitem>
	<para>
	  <option>-std=c++11</option> for the 2011 C++ standard.  This
	  option should not be used.
	</para>
      </listitem>
      <listitem>
	<para>
	  <option>-std=c++0x</option> for several different versions
	  of C++11 support in development, depending on the GCC
	  version.  This option should not be used.
	  <!-- There were two incompatibilies before GCC 4.7.2
	       (std::list and std::pair), but link C++98 and C++11
	       code is still unsupported, although it currently has
	       some chance of working by accident. -->
	</para>
      </listitem>
    </itemizedlist>
    <para>
      For each of these flags, there are variants which also enable
      GNU extensions (mostly language features also found in C99 or
      C11): <option>-std=gnu++98</option>,
      <option>-std=gnu++03</option>, <option>-std=gnu++11</option>.
      Again, <option>-std=gnu++11</option> should not be used.
    </para>
    <para>
      If you enable C++11 support, the ABI of the standard C++ library
      <literal>libstdc++</literal> will change in subtle ways.
      Currently, no C++ libraries are compiled in C++11 mode, so if
      you compile your code in C++11 mode, it will be incompatible
      with the rest of the system.  Unfortunately, this is also the
      case if you do not use any C++11 features.  Currently, there is
      no safe way to enable C++11 mode (except for freestanding
      applications).
    </para>
    <para>
      The meaning of C++0X mode changed from GCC release to GCC
      release.  Earlier versions were still ABI-compatible with C++98
      mode, but in the most recent versions, switching to C++0X mode
      activates C++11 support, with its compatibility problems.
    </para>
    <para>
      Some C++11 features (or approximations thereof) are available
      with TR1 support, that is, with <option>-std=c++03</option> or
      <option>-std=gnu++03</option> and in the
      <literal>&lt;tr1/*&gt;</literal> header files.  This includes
      <literal>std::tr1::shared_ptr</literal> (from
      <literal>&lt;tr1/memory&gt;</literal>) and
      <literal>std::tr1::function</literal> (from
      <literal>&lt;tr1/functional&gt;</literal>).  For other C++11
      features, the Boost C++ library contains replacements.
    </para>
  </section>
</section>

