File tidies, preparing for 8.32-RC1.

git-svn-id: svn://vcs.exim.org/pcre/code/trunk@1221 2f5784b3-3f2a-0410-8824-cb99058d5e15

1 files changed, 11 insertions, 11 deletions

diff --git a/doc/html/pcrejit.html b/doc/html/pcrejit.html
index 7161e71..6286fcc 100644
--- a/doc/html/pcrejit.html
+++ b/doc/html/pcrejit.html
@@ -64,7 +64,7 @@ JIT. The support is limited to the following hardware platforms:
   Intel x86 32-bit and 64-bit
   MIPS 32-bit
   Power PC 32-bit and 64-bit
-  SPARC 32-bit (experimental) 
+  SPARC 32-bit (experimental)
 </pre>
 If --enable-jit is set on an unsupported platform, compilation fails.
 </P>
@@ -73,8 +73,8 @@ A program that is linked with PCRE 8.20 or later can tell if JIT support is
 available by calling <b>pcre_config()</b> with the PCRE_CONFIG_JIT option. The
 result is 1 when JIT is available, and 0 otherwise. However, a simple program
 does not need to check this in order to use JIT. The normal API is implemented
-in a way that falls back to the interpretive code if JIT is not available. For 
-programs that need the best possible performance, there is also a "fast path" 
+in a way that falls back to the interpretive code if JIT is not available. For
+programs that need the best possible performance, there is also a "fast path"
 API that is JIT-specific.
 </P>
 <P>
@@ -407,18 +407,18 @@ callback.
 </P>
 <br><a name="SEC11" href="#TOC1">JIT FAST PATH API</a><br>
 <P>
-Because the API described above falls back to interpreted execution when JIT is 
-not available, it is convenient for programs that are written for general use 
-in many environments. However, calling JIT via <b>pcre_exec()</b> does have a 
-performance impact. Programs that are written for use where JIT is known to be 
+Because the API described above falls back to interpreted execution when JIT is
+not available, it is convenient for programs that are written for general use
+in many environments. However, calling JIT via <b>pcre_exec()</b> does have a
+performance impact. Programs that are written for use where JIT is known to be
 available, and which need the best possible performance, can instead use a
 "fast path" API to call JIT execution directly instead of calling
-<b>pcre_exec()</b> (obviously only for patterns that have been successfully 
+<b>pcre_exec()</b> (obviously only for patterns that have been successfully
 studied by JIT).
 </P>
 <P>
-The fast path function is called <b>pcre_jit_exec()</b>, and it takes exactly 
-the same arguments as <b>pcre_exec()</b>, plus one additional argument that 
+The fast path function is called <b>pcre_jit_exec()</b>, and it takes exactly
+the same arguments as <b>pcre_exec()</b>, plus one additional argument that
 must point to a JIT stack. The JIT stack arrangements described above do not
 apply. The return values are the same as for <b>pcre_exec()</b>.
 </P>
@@ -431,7 +431,7 @@ for validity. In the interests of speed, these checks do not happen on the JIT
 fast path, and if invalid data is passed, the result is undefined.
 </P>
 <P>
-Bypassing the sanity checks and the <b>pcre_exec()</b> wrapping can give 
+Bypassing the sanity checks and the <b>pcre_exec()</b> wrapping can give
 speedups of more than 10%.
 </P>
 <br><a name="SEC12" href="#TOC1">SEE ALSO</a><br>