NaCl doc: update release notes for M41

native_client_sdk/doc_generated/sdk/release-notes.html

 {{+bindTo:partials.standard_nacl_article}}
 
 <section id="release-notes">
 <span id="sdk-release-notes"></span><h1 id="release-notes"><span id="sdk-release-notes"></span>Release Notes</h1>
+<p>The dates in the following release notes denote when Chrome and the NaCl SDK
+reached canary status. The stable release is typically 6 weeks later.</p>
+<h2 id="chrome-pepper-42-20-february-2015">Chrome/Pepper 42 (20 February 2015)</h2>
+<h3 id="nacl">NaCl</h3>
+<ul class="small-gap">
+<li>The x86 NaCl validators accept instructions from the FMA3 extensions.</li>
+</ul>
+<h3 id="pnacl">PNaCl</h3>
+<ul class="small-gap">
+<li>PNaCl supports C11/C++11 memory orders <cite>acquire</cite>, <cite>release</cite>, and <cite>acq_rel</cite>. It
+used to upgrade all accesses to <cite>seq_cst</cite>. It still upgrades <cite>consume</cite> to
+<cite>acquire</cite> (no compiler currently implements <cite>consume</cite>), and <cite>relaxed</cite> to
+<cite>seq_cst</cite> (to conservatively avoid platform differences due to out-of-thin-air
+problems).</li>
+<li>PNaCl handles nested struct type expansion, which allows it to better support
+non-C languages such as Rust.</li>
+<li>PNaCl breaks up many integer operations over 64-bits into individual 64-bit
+operations. This is often encountered when using large consecutive bitfields.</li>
+</ul>
+<h2 id="chrome-pepper-41-09-january-2015">Chrome/Pepper 41 (09 January 2015)</h2>
+<h3 id="id1">NaCl</h3>
+<ul class="small-gap">
+<li>The x86 NaCl validators accept instructions from the AVX1 extensions.</li>
+</ul>
+<h3 id="id2">PNaCl</h3>
+<ul class="small-gap">
+<li>PNaCl is now based on LLVM 3.5.</li>
+</ul>
+<h2 id="chrome-pepper-40-november-07-2014">Chrome/Pepper 40 (November 07 2014)</h2>
+<ul class="small-gap">
+<li><a class="reference external" href="/native-client/pepper_stable/cpp/classpp_1_1_video_decoder.html">VideoDecoder</a> is now
+stable, see the SDK example in <code>pepper_canary/examples/api/video_decode</code>.</li>
+</ul>
 <h2 id="chrome-pepper-39-26-september-2014">Chrome/Pepper 39 (26 September 2014)</h2>
 <h3 id="pepper">Pepper</h3>
 <ul class="small-gap">
 <li>Support for <code>DEBUG_ONLY:dev://postmessage</code> has been removed in favor of
 <a class="reference internal" href="/native-client/devguide/devcycle/debugging.html#devcycle-debugging"><em>other more useful debugging approaches</em></a>.</li>
-<li><a class="reference external" href="/native-client/pepper_beta/cpp/classpp_1_1_video_decoder.html">VideoDecoder</a> is now
-stable, see the SDK example in <code>pepper_canary/examples/api/video_decode</code>.</li>
 <li><code>postMessageAndAwaitResponse</code> is now stable and allows JavaScript to
-communicate synchronously with PNaCl embeds.</li>
+<a class="reference external" href="/native-client/pepper_stable/cpp/classpp_1_1_message_handler">communicate synchronously</a> with PNaCl
+embeds.</li>
 </ul>
 <h2 id="chrome-pepper-38-15-august-2014">Chrome/Pepper 38 (15 August 2014)</h2>
-<h3 id="pnacl">PNaCl</h3>
+<h3 id="id3">PNaCl</h3>
 <ul class="small-gap">
 <li>Compilation speed improvements due to validation caching of the translator and
 linker.</li>
 <li>Performance improvement of SIMD vector shuffle.</li>
 </ul>
 <h2 id="chrome-pepper-37-20-june-2014">Chrome/Pepper 37 (20 June 2014)</h2>
-<h3 id="id1">PNaCl</h3>
+<h3 id="id4">PNaCl</h3>
 <ul class="small-gap">
 <li>2–10% translation time improvement.</li>
 <li>Improved vector load/store and shuffle performance.</li>
 </ul>
-<h3 id="id2">Pepper</h3>
+<h3 id="id5">Pepper</h3>
 <ul class="small-gap">
 <li>Media Streams Input support.</li>
 <li>Compositor API.</li>
 <li>Hardware Decode API in development preview.</li>
 <li>Sync API in development preview.</li>
 </ul>
 <h3 id="sdk">SDK</h3>
 <ul class="small-gap">
 <li>Demo of a <a class="reference internal" href="/native-client/io2014.html#io2014"><em>full development environment in the browser</em></a>.</li>
 </ul>
 <h2 id="chrome-pepper-36-09-may-2014">Chrome/Pepper 36 (09 May 2014)</h2>
-<h3 id="id3">PNaCl</h3>
+<h3 id="id6">PNaCl</h3>
 <ul class="small-gap">
 <li>Support <a class="reference external" href="http://clang.llvm.org/docs/LanguageExtensions.html#vectors-and-extended-vectors">LLVM vectors</a>
 and <a class="reference external" href="http://gcc.gnu.org/onlinedocs/gcc/Vector-Extensions.html">GCC vectors</a> for SIMD
 vectors through <a class="reference internal" href="/native-client/reference/pnacl-c-cpp-language-support.html#portable-simd-vectors"><em>Portable SIMD Vectors</em></a>. Note that this is still an early release,
 and performance is expected to become acceptable for version 37 of
 Chrome. More SIMD instructions will be added in later releases.</li>
 </ul>
 <h2 id="chrome-pepper-35-31-mar-2014">Chrome/Pepper 35 (31 Mar 2014)</h2>
-<h3 id="id4">PNaCl</h3>
+<h3 id="id7">PNaCl</h3>
 <ul class="small-gap">
 <li>Upgraded LLVM to version 3.4.</li>
 <li>Translation now uses dynamic load balancing, making translation time faster.</li>
 <li>Unstable pexes (i.e. non-finalized) with debug information can be loaded by
 Chrome, simplifying debugging with PNaCl. See <a class="reference internal" href="/native-client/devguide/devcycle/debugging.html#debugging-pnacl-pexes"><em>Debugging PNaCl pexes</em></a></li>
 </ul>
 <h2 id="chrome-pepper-34-20-feb-2014">Chrome/Pepper 34 (20 Feb 2014)</h2>
-<h3 id="id5">Pepper</h3>
+<h3 id="id8">Pepper</h3>
 <ul class="small-gap">
 <li>Filesystems can now be passed from JavaScript to NaCl. The resulting
 <code>pp::Var</code> will contain a <code>pp::Resource</code> that can be given to the
 <code>pp::FileSystem</code> constructor.</li>
 <li>New Audio and Video input APIs have been added as dev interfaces. See
 <a class="reference external" href="/native-client/pepper_dev/cpp/classpp_1_1_media_stream_audio_track">pp::MediaStreamAudioTrack</a> and
 <a class="reference external" href="/native-client/pepper_dev/cpp/classpp_1_1_media_stream_video_track">pp::MediaStreamVideoTrack</a> for
 more details.</li>
 </ul>
-<h3 id="id6">PNaCl</h3>
+<h3 id="id9">PNaCl</h3>
 <ul class="small-gap">
 <li>Parallel translation: at least 1.7x faster, even with older pexes.</li>
 <li>Intelligent abbreviations in the bitcode: 20% reduction in binary size using
 the <a class="reference internal" href="/native-client/devguide/devcycle/building.html#pnacl-compress"><em>pnacl-compress</em></a> tool.</li>
 </ul>
 <h2 id="chrome-pepper-33-16-dec-2013">Chrome/Pepper 33 (16 Dec 2013)</h2>
 <h3 id="portable-native-client">Portable Native Client</h3>
 <ul class="small-gap">
 <li>PNaCl&#8217;s default C++ standard library is now LLVM&#8217;s own libc++, based on
 LLVM 3.3. This library now supports optional <code>setjmp</code>/<code>longjmp</code> exception
 handling (see <a class="reference external" href="https://groups.google.com/forum/#!topic/native-client-discuss/0spfg6O04FM">announcement</a>
 for details).</li>
 </ul>
-<h3 id="id7">SDK</h3>
+<h3 id="id10">SDK</h3>
 <ul class="small-gap">
 <li>The <code>nacl_io</code> library now includes a FUSE mount.</li>
 <li>In the SDK examples, <code>common.js</code> now loads the Release version of the
 nexes/pexes that are built (by default).</li>
 <li>&#8220;<code>make debug</code>&#8221; and &#8220;<code>make run</code>&#8221; have been fixed on Mac.</li>
 </ul>
 <h2 id="pnacl-enabled-by-default-in-chrome-31-12-nov-2013">PNaCl enabled by default in Chrome 31 (12 Nov 2013)</h2>
 <ul class="small-gap">
 <li>Portable Native Client (PNaCl) is enabled by default in Chrome 31. See
 <a class="reference internal" href="/native-client/nacl-and-pnacl.html"><em>NaCl and PNaCl</em></a> for details on the differences between
@@ skipping 93 matching lines @@
 <ul class="small-gap">
 <li>Common makefiles, including <code>tools/common.mk</code>, can now handle source files
 located outside of an application&#8217;s root directory. For example, a Makefile
 for an application can specify a source file to compile such as
 <code>../../some/other/place.cpp</code>.</li>
 </ul>
 <h2 id="pepper-26-29-march-2013">Pepper 26 (29 March 2013)</h2>
 <p>The Pepper 26 bundle includes a new HTTP filesystem type in the nacl_mounts
 library (which has been renamed nacl_io), changes to the example Makefiles, a
 simple new 3D example, and a threaded file IO example.</p>
-<h3 id="id8">Build tools and toolchains</h3>
+<h3 id="id11">Build tools and toolchains</h3>
 <ul class="small-gap">
 <li><p class="first">Makefiles have been changed significantly:</p>
 <ul class="small-gap">
 <li>Build commands are now specified in a number of common files
 (<code>tools/*.mk</code>), which are included in the Makefiles in the examples.</li>
 <li>By default, make displays a simplified list of build steps (e.g., <code>CC
 newlib/Debug/hello_world_x86_32.o</code>) rather than the actual build commands.
 To see the actual build commands, run <code>make V=1</code>.</li>
 <li>By default, most examples are built using one toolchain (newlib) and one
 configuration (Debug). To build an example using a different toolchain or
 configuration, run <code>make</code> with the parameters <code>TOOLCHAIN=&lt;x&gt;</code> or
 <code>CONFIG=&lt;y&gt;</code>.  You can also run make <code>all_versions</code> to build an example
 with all toolchains.</li>
 </ul>
 </li>
 <li>Header files have been moved out of the toolchains. All toolchains now share
 the same set of header files as host builds. Previously host and NaCl builds
 used different headers, which could cause build problems.</li>
 </ul>
-<h3 id="id9">Libraries</h3>
+<h3 id="id12">Libraries</h3>
 <ul class="small-gap">
 <li>The nacl_mounts library has been renamed <strong>nacl_io</strong>, and has been expanded
 with a new type of mount, httpfs, which can be used to read URLs via HTTP.
 For details see <code>include/nacl_io/nacl_io.h</code>, as well as the
 <code>hello_nacl_io</code> example.</li>
 </ul>
-<h3 id="id10">Examples</h3>
+<h3 id="id13">Examples</h3>
 <ul class="small-gap">
 <li>A new example, <strong>hello_world_instance3d</strong>, has been added to demonstrate a
 simplified 3D app.</li>
 <li>The <strong>file_io</strong> example has been rewritten to do all file operations on a
 thread.  The example demonstrates how to use the MessageLoop API and blocking
 callbacks on a thread.</li>
 </ul>
 <h3 id="general">General</h3>
 <ul class="small-gap">
 <li>Old bundles (<code>pepper_20</code> and earlier) have been removed from the Native
 Client SDK Manifest, and will no longer be updated by the <code>naclsdk</code>
 command.</li>
 </ul>
 <h2 id="pepper-25-21-december-2012">Pepper 25 (21 December 2012)</h2>
 <p>The Pepper 25 bundle features an ARM toolchain to build Native Client modules
 for ARM devices, two new Pepper APIs (including the MessageLoop API, which lets
 you make Pepper calls on background threads), two new libraries (nacl_mounts,
 which provides a virtual file system that you can use with standard C file
 operations, and ppapi_main, which lets you implement a Native Client module
 using a simple ppapi_main function), and two new examples that demonstrate how
 to use the nacl_mounts and ppapi_main libraries.</p>
-<h3 id="id11">Build tools and toolchains</h3>
+<h3 id="id14">Build tools and toolchains</h3>
 <ul class="small-gap">
 <li><p class="first">The SDK includes a new toolchain to build Native Client executables (.nexe
 files) for <strong>ARM devices</strong>.</p>
 <ul class="small-gap">
 <li>Currently the ARM toolchain can only be used to compile modules that use
 the <a class="reference internal" href="/native-client/devguide/devcycle/dynamic-loading.html#c-libraries"><em>newlib C library</em></a>. You cannot use the ARM toolchain
 to compile modules that use the glibc library.</li>
 <li>The ARM toolchain is in the directory
 <code>pepper_25/toolchain/&lt;host&gt;_arm_newlib</code>.  The bin subdirectory contains
 the compiler (<code>arm-nacl-gcc</code>), the linker (<code>arm-nacl-g++</code>), and the
@@ skipping 16 matching lines @@
 module log messages to the JavaScript console in the Chrome browser.</li>
 <li>The <a class="reference external" href="/native-client/pepper_stable/cpp/classpp_1_1_message_loop">MessageLoop</a> API lets your
 module make PPAPI calls on a background thread.  Once you&#8217;ve created a
 message loop resource, attached it to a thread, and run it, you can post work
 to the thread, including completion callbacks for asynchronous operations.
 For a C++ example of how to use the MessageLoop API, see
 <code>pepper_25/include/ppapi/utility/threading/simple_thread.h</code>. Note that you
 cannot make asynchronous PPAPI calls on a background thread without creating
 and using a message loop.</li>
 </ul>
-<h3 id="id12">Libraries</h3>
+<h3 id="id15">Libraries</h3>
 <p>The SDK includes two new libraries:</p>
 <ul class="small-gap">
 <li><p class="first">The <strong>nacl_mounts</strong> library provides a virtual file system that your module
 can &#8220;mount&#8221; in a given directory tree. The file system can be one of several
 types:</p>
 <ul class="small-gap">
 <li>&#8220;memfs&#8221; is an in-memory file system,</li>
 <li>&#8220;dev&#8221; is a file system with various utility nodes (e.g., <code>/dev/null</code>,
 <code>/dev/console[0-3]</code>, <code>/dev/tty</code>), and</li>
 <li>&#8220;html5fs&#8221; is a persistent file system.</li>
@@ skipping 13 matching lines @@
 providing a familiar C programming environment. With this library, your
 module can have a simple entry point called ppapi_main(), which is similar to
 the standard C main() function, complete with argc and argv[] parameters.
 Your module can also use standard C functions such as printf(), fopen(), and
 fwrite(). For details see include/ppapi_main/ppapi_main.h. For an example of
 how to use ppapi_main, see examples/hello_world_stdio.</li>
 </ul>
 <p>Header files for the new libraries are in the <code>include/</code> directory, source
 files are in the <code>src/</code> directory, and compiled libraries are in the <code>lib/</code>
 directory.</p>
-<h3 id="id13">Examples</h3>
+<h3 id="id16">Examples</h3>
 <ul class="small-gap">
 <li><p class="first">The SDK includes two new examples:</p>
 <ul class="small-gap">
 <li><strong>hello_nacl_mounts</strong> illustrates how to use standard C library file
 operations in a Native Client module through the use of the nacl_mounts
 library.</li>
 <li><strong>hello_world_stdio</strong> illustrates how to implement a Native Client module
 with a ppapi_main() function, and how to write to STDOUT and STDERR in a
 module, through the use of the nacl_mounts and ppapi_main libraries. This
 example makes it easy for new users to get started with Native Client by
@@ skipping 20 matching lines @@
 Chrome is closed, the local server is shut down as well.</li>
 <li>The hello_world_stdio example includes a simplified Makefile that only lists
 source dependencies, and invokes the build rules in a separate file
 (common.mk).</li>
 </ul>
 <h2 id="pepper-24-5-december-2012">Pepper 24 (5 December 2012)</h2>
 <p>The Pepper 24 bundle features a new, experimental toolchain called PNaCl (short
 for &#8220;Portable Native Client&#8221;), a new library (pthreads-win32) for the Windows
 SDK, and an expanded list of attributes for Pepper 3D contexts that lets
 applications specify a GPU preference for low power or performance.</p>
-<h3 id="id14">Build tools and toolchains</h3>
+<h3 id="id17">Build tools and toolchains</h3>
 <ul class="small-gap">
 <li>The SDK includes a new, experimental toolchain called <a class="reference external" href="http://nativeclient.googlecode.com/svn/data/site/pnacl.pdf">PNaCl</a> (pronounced
 &#8220;pinnacle&#8221;). The PNaCl toolchain produces architecture-independent executable
 files (.pexe files). Chrome doesn&#8217;t yet support .pexe files directly, but if
 you want to experiment with this early preview of PNaCl, the toolchain
 includes a tool to translate .pexe files into architecture-specific .nexe
 files. Take a look at the <code>hello_world</code> example to see how to build a .pexe
 file and translate it into multiple .nexe files. Note that PNaCl is currently
 restricted to the newlib C standard library – if your application uses glibc,
 you can&#8217;t build it with PNaCl.</li>
 <li>The <code>create_nmf.py</code> script uses ELF headers (rather than file names) to
 determine the architecture of .nexe files. That means you can change the
 names of your .nexe files and <code>create_nmf.py</code> will still be able to
 generate the appropriate Native Client manifest file for your application.</li>
 </ul>
-<h3 id="id16">Examples</h3>
+<h3 id="id19">Examples</h3>
 <ul class="small-gap">
 <li>The SDK examples now build with four toolchains: the glibc and newlib
 toolchains, the experimental PNaCl toolchain, and the hosted toolchain on
 your development machine. Within each toolchain build, each example also
 builds both a debug and a release version.</li>
 <li>The example Makefiles use dependency (.d) files to enable incremental builds.</li>
 <li>The pong example has been cleaned up and modified to run more smoothly. The
 drawing function is now set up as the Flush() callback, which allows 2D
 drawing to occur as quickly as possible.</li>
 </ul>
-<h3 id="id17">PPAPI</h3>
+<h3 id="id20">PPAPI</h3>
 <ul class="small-gap">
 <li>When creating a 3D rendering context, the <a class="reference external" href="/native-client/pepper_stable/c/group___enums#ga7df48e1c55f6401beea2a1b9c07967e8">attribute list</a>
 for the context can specify whether to prefer low power or performance for
 the GPU. Contexts with a low power preference may be created on an integrated
 GPU; contexts with a performance preference may be created on a discrete GPU.</li>
 </ul>
 <h3 id="windows-sdk">Windows SDK</h3>
 <ul class="small-gap">
 <li>The Windows SDK includes the pthreads-win32 library to assist in porting from
 win32 code. You can use this library when developing your module as a Pepper
@@ skipping 51 matching lines @@
 <ul class="small-gap">
 <li>Look at the example Makefiles or run <code>make</code> in the example directories to
 see the commands and flags used to build modules as Pepper plugins.</li>
 <li>Run <code>make LAUNCH</code> in the example directories to see how to use the
 <code>--register-pepper-plugins</code> argument to load a Pepper plugin in Chrome.
 Note that you must set the <code>CHROME_PATH</code> environment variable and start a
 <a class="reference internal" href="/native-client/devguide/devcycle/running.html#web-server"><em>local server</em></a> prior to running this command.</li>
 </ul>
 </li>
 </ul>
-<h3 id="id18">Examples</h3>
+<h3 id="id21">Examples</h3>
 <ul class="small-gap">
 <li>On Linux and Windows systems, most of the examples now build with three
 toolchains: the Native Client glibc and newlib toolchains, and the native
 toolchain on the host system. Modules built with the native toolchain on the
 host system can only run as Pepper plugins.</li>
 <li>All examples in the SDK now comply with version 2 of the Chrome Web Store
 <a class="reference external" href="/extensions/manifest">manifest file format</a>. By default,
 applications that use version 2 of the manifest file format apply a strict
 <a class="reference external" href="/extensions/contentSecurityPolicy">content security policy</a>, which
 includes a restriction against inline JavaScript. This restriction prohibits
 both inline <code>&lt;script&gt;</code> blocks and inline event handlers (e.g., <code>&lt;button
 onclick=&quot;...&quot;&gt;</code>).  See <a class="reference external" href="/extensions/manifestVersion">Manifest Version</a> for
 a list of changes between version 1 and version 2 of the manifest file
 format, and a support schedule for applications that use version 1.</li>
 </ul>
-<h3 id="id19">PPAPI</h3>
+<h3 id="id22">PPAPI</h3>
 <ul class="small-gap">
 <li><a class="reference external" href="/native-client/pepper_stable/c/group___enums#ga21b811ac0484a214a8751aa3e1c959d9">PP_InputEvent_Modifier</a>
 has two new enum values (_ISLEFT and _ISRIGHT).</li>
 <li>The memory leak in the <a class="reference external" href="/native-client/pepper_stable/c/struct_p_p_b___web_socket__1__0">WebSocket</a> API has
 been fixed.</li>
 </ul>
 <h2 id="pepper-22-22-august-2012">Pepper 22 (22 August 2012)</h2>
 <p>The Pepper 22 bundle includes a <strong>command-line debugger</strong>, resources to enable
 <strong>hosted development on Windows</strong>, and changes to the example Makefiles (each
 example now builds both a debug and a release version).</p>
-<h3 id="id20">Tools</h3>
+<h3 id="id23">Tools</h3>
 <ul class="small-gap">
 <li>The SDK now includes a <strong>command-line debugger</strong> that you can use to debug
 Native Client modules. See <a class="reference internal" href="/native-client/devguide/devcycle/debugging.html#devcycle-debugging"><em>Debugging with nacl-gdb</em></a> for instructions on how to use this debugger. For now,
 nacl-gdb only works on 64-bit Windows, 64-bit Linux, and 32-bit Linux
 systems. Support for Mac and 32-bit Windows systems will be added soon.</li>
 </ul>
-<h3 id="id21">Windows SDK</h3>
+<h3 id="id24">Windows SDK</h3>
 <ul class="small-gap">
 <li><p class="first">Developers using the Windows SDK can now <strong>build a module as a Pepper
 plugin</strong> (sometimes called a &#8220;trusted&#8221; or &#8220;in-process&#8221; plugin) using the
 native C/C++ compiler on their development system. In essence this makes
 developing a Native Client module a two-step process:</p>
 <ol class="arabic simple">
 <li>Build the module into a DLL using your system&#8217;s C/C++ compiler. Test and
 debug the DLL using the tools in your normal development environment.</li>
 <li>Build the module into a .nexe using the compiler from one of the Native
 Client toolchains in the SDK (nacl-gcc or nacl-g++). Test and debug the
@@ skipping 27 matching lines @@
 <strong>Note:</strong> It&#8217;s also possible to build a module as a trusted plugin on Mac and
 Linux systems, but doing so requires more work because the SDK does not yet
 include the above resources (library source files and pre-built libraries)
 for Mac and Linux systems. To build and debug a trusted plugin on Mac and
 Linux systems, you need to <a class="reference external" href="http://dev.chromium.org/developers/how-tos/get-the-code">get the Chromium code</a> and then follow
 the <a class="reference external" href="http://www.chromium.org/nativeclient/how-tos/debugging-documentation/debugging-a-trusted-plugin/trusted-debugging-on-mac">Mac instructions</a>
 or <a class="reference external" href="http://www.chromium.org/nativeclient/how-tos/debugging-documentation/debugging-a-trusted-plugin/debugging-a-trusted-plugin-on-linux">Linux instructions</a>.
 In the future, the SDK will include resources for hosted development on Mac
 and Linux as well as Windows.
 </aside>
-<h3 id="id22">Examples</h3>
+<h3 id="id25">Examples</h3>
 <ul class="small-gap">
 <li>Each example in the SDK now builds both a debug and a release version. As
 before, most examples also build newlib and glibc versions, which means that
 there are now four versions for each example. Take a look at the Makefiles in
 the examples to see the compiler flags that are used for debug and release
 versions. For a description of those flags, see <a class="reference internal" href="/native-client/devguide/devcycle/building.html#compile-flags"><em>Compile flags for
 different development scenarios</em></a>.</li>
 <li>Comments have been added to common.js, which is used in all the examples. The
 JavaScript in common.js inserts an &lt;embed&gt; element that loads the NaCl module
 in each example&#8217;s web page, attaches event listeners to monitor the loading
 of the module, and implements handleMessage() to respond to messages sent
 from the NaCl module to the JavaScript side of the application</li>
 </ul>
-<h3 id="id23">PPAPI</h3>
+<h3 id="id26">PPAPI</h3>
 <ul class="small-gap">
 <li>The <code>CompletionCallbackFactory</code> class template now takes a thread traits
 class as its second parameter. For details see the <a class="reference external" href="/native-client/pepper_stable/cpp/classpp_1_1_completion_callback_factory#details">CompletionCallbackFactory
 class template reference</a>.</li>
 </ul>
 </section>
 
 {{/partials.standard_nacl_article}}