Minor changes here and there.

Including that pbcopy and clip have both been verified.

index.html

@@ -158,7 +158,7 @@ llOwnerSay("Program version " STRINGIFY(VERSION)
 
 <h3><a id="extensions-type-cast-extension"></a>Type-cast extension</h3>
 
-<p>For some reason, LSL only allows postfix expressions after a type cast. This extends the syntax to allow prefix expressions as well. This means that you can write e.g. <code>(string)(integer)a</code> instead of <code>(string)((integer)a)</code>, or <code>(string)++x</code> instead of <code>(string)(++x)</code>, sparing you from having to enter the extra parentheses.</p>
+<p>For some reason, LSL only allows postfix expressions after a type cast. This feature extends the syntax to allow prefix expressions as well. This means that you can write e.g. <code>(string)(integer)a</code> instead of <code>(string)((integer)a)</code>, or <code>(string)++x</code> instead of <code>(string)(++x)</code>, sparing you from having to enter the extra parentheses.</p>
 
 <h3><a id="extensions-multiple-labels-with-the-same-name"></a>Multiple labels with the same name</h3>
 
@@ -198,7 +198,7 @@ llOwnerSay("Program version " STRINGIFY(VERSION)
 
 <h3><a id="extensions-preproc-cmds"></a>#pragma and #line</h3>
 
-<p>The optimizer option <code>ProcessPre</code> enables processing of certain preprocessor directives that control compilation. Only <code>#pragma</code> and <code>#line</code> are supported for now. Typically these directives pass through the preprocessor unchanged, so they will reach the optimizer if a preprocessor is used. The rest of preprocessor directives will be ignored.</p>
+<p>The optimizer option <code>ProcessPre</code> enables processing of certain preprocessor directives that control compilation. Only <code>#pragma</code> and <code>#line</code> are supported for now. Typically these directives pass through the preprocessor unchanged (not always; see note below about <code>gcc</code> and <code>#line</code>), so they will reach the optimizer if a preprocessor is used. The rest of preprocessor directives will be ignored.</p>
 
 <p><code>#pragma</code> is a special C preprocessor directive that allows compilers to extend the language with certain options. In the case of this optimizer, the <code>#pragma</code> directive is used to enable/disable on the fly the parsing options and extensions. Even <code>ProcessPre</code> itself can be disabled (it can't be enabled this way because when disabled, <code>#pragma</code> directives aren't processed).</p>
 
@@ -247,7 +247,7 @@ FuncOverride
 
 <p><i><b>Note:</b> <em>GNU cpp</em> actually generates a preprocessor command that only contains the line number and the file name, pretty much like a </i><code>#line</code><i> directive does, but without the </i><code>line</code><i> part. The parser deals with that format correctly, treating it as if it was a </i><code>#line</code><i> directive.</i></p>
 
-<p><i><b>Note:</b> Firestorm prepends a <em><code>//</code></em> comment to the </i><code>#line</code><i> directives that <em>Boost::Wave</em> generates; since the optimizer doesn't use Firestorm's output directly, it doesn't interpret these lines.</i></p>
+<p><i><b>Note:</b> Firestorm prepends a <em><code>//</code></em> comment to the </i><code>#line</code><i> directives that <em>Boost::Wave</em> generates; since the optimizer doesn't use Firestorm's output directly, it doesn't interpret these lines specially.</i></p>
 
 <p><i><b>Note:</b> Pragma operators of the form </i><code>_Pragma("pragma string")</code><i> introduced in <em>C99</em> are not supported.</i></p>
 
@@ -267,7 +267,7 @@ FuncOverride
 
 <ol>
 <li><code>case</code> labels can't appear in nested blocks. That's because they are replaced by LSL labels, and as discussed in the <em>Multiple labels with the same name</em> section above, label scope rules prevent their visibility in an outer block, so once converted to labels, the corresponding <code>jump</code> instructions would not be able to find them. This limitation means that <a href="https://en.wikipedia.org/wiki/Duff's_device">Duff's device</a> or similar constructs can't be implemented with this optimizer.</li>
-<li><div><code>switch()</code> needs to be followed by a block, not by a single statement. For example, whiile this works in C, it won't work in this optimizer:</div>
+<li><div><code>switch()</code> needs to be followed by a block, not by a single statement. For example, while this works in C, it won't work in this optimizer:</div>
 <pre><code>    switch(1) case 1: break;</code></pre>
 <div>The reason is that <code>case</code> is treated by this parser as a statement, rather than as a label prefix, making <code>break</code> be outside the <code>switch</code> and thus failing at that point. This limitation is probably only of theoretical importance and will not have any practical implication, since single-statement <code>switch</code> clauses are of little or no practical use (known to the author). Of course it works perfectly when enclosed in braces:</div>
 <pre><code>    switch(1) { case 1: break; }</code></pre></li>
@@ -438,12 +438,12 @@ string b = "A very long string that appears in this script once" + " or twice";
 notepad temp.opt
 </code></pre>
 
-<p>will, under any system which has an editor called <code>notepad</code>, read <code>myscript.lsl</code>, optimize it, and write the optimized result to <code>temp.opt</code>, then open it in the editor, enabling you to copy it and paste it into the viewer. Under <em>Windows</em> version <em>Vista</em> and above, apparently there's a command line application called <code>clip</code> that does the same as <code>xclip</code> does for <em>X Window</em>, enabling you to use this:</p>
+<p>will, under any system which has an editor called <code>notepad</code>, read <code>myscript.lsl</code>, optimize it, and write the optimized result to <code>temp.opt</code>, then open it in the editor, enabling you to copy it and paste it into the viewer. Under <em>Windows</em> version <em>Vista</em> and above, there's a command line application called <code>clip</code> that does the same as <code>xclip</code> does for <em>X Window</em>, enabling you to use this:</p>
 
 <pre><code>python main.py myscript.lsl | clip
 </code></pre>
 
-<p>to copy the optimized output to the clipboard. Under OS X, it seems <code>pbcopy</code> does the same as <code>xclip</code> and <code>clip</code>.</p>
+<p>to copy the optimized output to the clipboard. Under OS X, <code>pbcopy</code> does the same as <code>xclip</code> and <code>clip</code>.</p>
 
 <p>An external preprocessor is supported. If your system has a GNU C Compiler suite already installed, then the <code>cpp</code> that comes with it (or <code>gcc</code> adding the <code>-E</code> option) should be enough. If you don't have it, the recommended preprocessor is <em>mcpp</em>, because it's a standalone executable, easy to install. Download it from <a href="http://mcpp.sourceforge.net/download.html">http://mcpp.sourceforge.net/download.html</a>, unpack the executable somewhere in the system path (or specify the path to the executable every time with the <code>--precmd</code> option of the program) and you're ready to go.</p>