PNaCl docs: Fix links to 'undefined behavior'

native_client_sdk/doc_generated/reference/pnacl-c-cpp-language-support.html

 {{+bindTo:partials.standard_nacl_article}}
 
 <section id="pnacl-c-c-language-support">
 <h1 id="pnacl-c-c-language-support">PNaCl C/C++ Language Support</h1>
 <div class="contents local" id="contents" style="display: none">
 <ul class="small-gap">
 <li><p class="first"><a class="reference internal" href="#source-language-support" id="id2">Source language support</a></p>
 <ul class="small-gap">
 <li><a class="reference internal" href="#versions" id="id3">Versions</a></li>
 <li><a class="reference internal" href="#preprocessor-definitions" id="id4">Preprocessor definitions</a></li>
@@ skipping 53 matching lines @@
 <h3 id="memory-model-for-concurrent-operations">Memory Model for Concurrent Operations</h3>
 <p>The memory model offered by PNaCl relies on the same coding guidelines
 as the C11/C++11 one: concurrent accesses must always occur through
 atomic primitives (offered by <a class="reference external" href="PNaClLangRef.html#atomicintrinsics">atomic intrinsics</a>), and these accesses must always
 occur with the same size for the same memory location. Visibility of
 stores is provided on a happens-before basis that relates memory
 locations to each other as the C11/C++11 standards do.</p>
 <p>Non-atomic memory accesses may be reordered, separated, elided or fused
 according to C and C++&#8217;s memory model before the pexe is created as well
 as after its creation. Accessing atomic memory location through
-non-atomic primitives is <cite>Undefined Behavior &lt;undefined_behavior&gt;</cite>.</p>
+non-atomic primitives is <a class="reference internal" href="/native-client/reference/pnacl-undefined-behavior.html#undefined-behavior"><em>Undefined Behavior</em></a>.</p>
 <p>As in C11/C++11 some atomic accesses may be implemented with locks on
 certain platforms. The <code>ATOMIC_*_LOCK_FREE</code> macros will always be
 <code>1</code>, signifying that all types are sometimes lock-free. The
 <code>is_lock_free</code> methods and <code>atomic_is_lock_free</code> will return the
 current platform&#8217;s implementation at translation time. These macros,
 methods and functions are in the C11 header <code>&lt;stdatomic.h&gt;</code> and the
 C++11 header <code>&lt;atomic&gt;</code>.</p>
 <p>The PNaCl toolchain supports concurrent memory accesses through legacy
 GCC-style <code>__sync_*</code> builtins, as well as through C11/C++11 atomic
 primitives and the underlying <a class="reference external" href="http://gcc.gnu.org/wiki/Atomic/GCCMM">GCCMM</a> <code>__atomic_*</code>
@@ skipping 91 matching lines @@
 consistent memory barrier (equivalent to <code>__sync_synchronize()</code>). In
 PNaCl this barrier is only guaranteed to order <code>volatile</code> and atomic
 memory accesses, though in practice the implementation attempts to also
 prevent reordering of memory accesses to objects which may escape.</p>
 <p>NaCl supports a fairly wide subset of inline assembly through GCC&#8217;s
 inline assembly syntax, with the restriction that the sandboxing model
 for the target architecture has to be respected.</p>
 </section><section id="undefined-behavior">
 <h2 id="undefined-behavior">Undefined Behavior</h2>
 <p>The C and C++ languages expose some undefined behavior which is
-discussed in <cite>PNaCl Undefined Behavior &lt;undefined_behavior&gt;</cite>.</p>
+discussed in <a class="reference internal" href="/native-client/reference/pnacl-undefined-behavior.html#undefined-behavior"><em>PNaCl Undefined Behavior</em></a>.</p>
 </section><section id="floating-point">
 <h2 id="floating-point">Floating-Point</h2>
 <p>PNaCl exposes 32-bit and 64-bit floating point operations which are
 mostly IEEE-754 compliant. There are a few caveats:</p>
 <ul class="small-gap">
 <li>Some <a class="reference internal" href="/native-client/reference/pnacl-undefined-behavior.html#undefined-behavior-fp"><em>floating-point behavior is currently left as undefined</em></a>.</li>
 <li>The default rounding mode is round-to-nearest and other rounding modes
 are currently not usable, which isn&#8217;t IEEE-754 compliant. PNaCl could
 support switching modes (the 4 modes exposed by C99 <code>FLT_ROUNDS</code>
 macros).</li>
@@ skipping 61 matching lines @@
 <p>Neither PNaCl nor NaCl currently support asynchronous interruption
 or suspension of threads.</p>
 </li>
 </ul>
 <p>If PNaCl were to support either of these, the interaction of
 <code>volatile</code> and atomics with same-thread signal handling would need
 to be carefully detailed.</p>
 </section></section></section>
 
 {{/partials.standard_nacl_article}}