Fixes in html files in 1986/marshall

This includes the compilers.html and index.html file.

I also threw in a slight formatting change in the thanks file.

1986/marshall/compilers.html

@@ -426,63 +426,67 @@
 
 <!-- BEFORE: 1st line of markdown file: 1986/marshall/compilers.md -->
 <h1 id="conflicting-compilers-and-optimisers-that-broke-this-entry-in-2023">Conflicting compilers and optimisers that broke this entry in 2023</h1>
-<p>As briefly noted in the <a href="index.html">index.html</a> <code>gcc</code> and <code>clang</code> caused different
-problems with this entry depending on the optimiser being enabled or not, where
-if the optimiser was enabled it would work with one compiler and not the other.
-But if you then disabled the optimiser the opposite problem would occur: the
-working compiler would no longer work and the non-functional one would start to
-work! And then there’s the problem of linux versus macOS causing problems.</p>
-<p>The <a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1986/marshall/marshall.alt.c">alternate code</a> (source code) demonstrates the problem so
-you can see if your compiler has the problem as described below.</p>
+<p>As briefly noted in the <a href="index.html">index.html</a> <code>gcc</code> versus <code>clang</code> caused
+different problems with this entry, depending on the optimiser being enabled or
+disabled, where if the optimiser was enabled it would work with one compiler but
+not the other; on the other hand, if you disabled the optimiser the opposite
+problem would occur: the working compiler would no longer work and the other one
+would! And then there’s the problem of linux versus macOS causing problems.</p>
+<p>Using the <a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1986/marshall/marshall.alt.c">alternate source code</a>
+demonstrates the problem so you can see if your compiler has the problem
+described below.</p>
 <p>In some versions of <code>gcc</code> and <code>clang</code> (this was first discovered in fedora linux 38)
-if the compiler was enabled one compiler would generate code that segfaulted but
-the other one would not. However, when then disabling the optimiser the compiler
-that had no problem suddenly did and the one that did suddenly did not. But
+if the optimiser was enabled one compiler would generate code that segfaulted but
+the other one did not. However, when disabling the optimiser, the compiler
+that had no problem suddenly <em>did</em> and the one that did suddenly <em>did not</em>. But
 segfaulting was not by any means the only problem.</p>
 <p>Another problem was that depending on the optimiser an infinite loop would be
 entered. But then removing it would cause other problems as well, including a
-segfault.</p>
+segfault!</p>
 <p>It was not only one compiler that dumped core. Both dumped core with other
-behaviour, depending on what changes in code were made and the optimiser being
-on or off. <code>Clang</code> in macOS also dumped core!</p>
+behaviour, depending on what changes in code were made, and the optimiser being
+on or off. <code>clang</code> in macOS also dumped core!</p>
 <p>The <a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1986/marshall/marshall.c">marshall.c</a> has the original fix
-for <code>clang</code> which works with some compilers depending on the optimiser. When we
-refer to the code below we refer to the alternate code,
-<a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1986/marshall/marshall.alt.c">marshall.alt.c</a>.</p>
+for <code>clang</code>, which works with some compilers, depending on the optimiser. Below
+we refer to the <a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1986/marshall/marshall.alt.c">alternate code
+marshall.alt.c</a>.</p>
 <h2 id="the-conflicting-compiler-problems">The conflicting compiler problems:</h2>
 <p>Below we describe the conflicting options that resulted in the need to modify
 the original code.</p>
 <h3 id="linux">Linux</h3>
-<p>With the optimiser disabled <code>GCC</code> compiled the code to enter an infinite loop.
-If the optimiser was enabled it worked fine. But if the optimiser is enabled
-<code>clang</code> generates code that first prints the text twice (it should print it once) and
-then immediately dumps core!</p>
-<p>But then there’s that infinite loop. What happens if we remove it?</p>
-<p>Once the loop is removed if we compile with <code>clang</code> and the optimiser is disabled
+<p>With the optimiser disabled <code>gcc</code> compiled the code to enter an infinite loop.
+If the optimiser was enabled it worked fine, but if the optimiser is enabled
+<code>clang</code> generates code that first prints the text twice (when it should print it
+only once) and then immediately dumps core!</p>
+<p>But then there’s that infinite loop. What happens if we fix it?</p>
+<p>Once the loop is removed, if we compile with <code>clang</code> and the optimiser is disabled
 all is okay. If however we compile with <code>gcc</code> and the optimiser is disabled the
 string is printed once and then the program dumps core! Why is this? It is
-because of the call to <code>_exit()</code> (see below).</p>
-<p><code>Clang</code> works fine with the loop removed and the optimiser disabled. If however we
-enable the optimiser <code>clang</code> will generate code that prints the string twice and
-dumps core just like before! What about the call to <code>_exit()</code>?</p>
-<p>The call was:</p>
+because of the call to the <code>_exit(2)</code> syscall (see below).</p>
+<p><code>clang</code> works fine with the loop removed if the optimiser is disabled. Once we
+enable it, though, it will generate code that prints the string twice and
+dumps core, just like before!</p>
+<div id="exit">
+<h3 id="what-about-the-call-to-the-_exit2-syscall">What about the call to the <code>_exit(2)</code> syscall?</h3>
+</div>
+<p>The call <em>was</em>:</p>
 <pre><code>    _exit(argv[(int)*argc-2/cc[1*(int)*argc]|-1&lt;&lt;4]);</code></pre>
-<p>Changing it to not refer to these variables and just exit 1 and the problems
-disappear!</p>
+<p>In the fixed code, these variables are simply commented out so the code does
+<code>_exit(1)</code>.</p>
 <h3 id="macos">macOS</h3>
-<p>But then there was macOS which had another problem!</p>
-<p>If the infinite loop is not removed/commented out and the optimiser is enabled
-it works fine but if it’s disabled it prints out the string and then enters an
-infinite loop!</p>
-<p>After we fix the infinite loop if we change the <code>_exit()</code> call in macOS and
-disable the optimiser we might get something like:</p>
+<p>Now as for macOS, <em>another problem</em> existed!</p>
+<p>If the code that resulted in an infinite loop is <em>NOT</em> commented out <em>AND</em> the
+optimiser is enabled it works fine; but if it [the optimiser] is disabled, it
+prints out the string and then enters that infinite loop!</p>
+<p>After we fix the infinite loop issue, if we change the call to the <code>_exit(2)</code>
+syscall in macOS and disable the optimiser we might get something like:</p>
 <pre><code>    $ ./marshall
           choo choo
     Segmentation fault: 11</code></pre>
 <p>Observe how it doesn’t print it twice. But of course it segfaults so it’s not
 right either.</p>
 <p>If the optimiser is enabled, however, we will see that it works fine before the
-change to <code>_exit()</code>.</p>
+change to the call to the <code>_exit(2)</code> syscall.</p>
 <h2 id="summary">Summary</h2>
 <p>And that is the tale of a little <del>engine</del> train that
 could…eventually! Or perhaps it’s the compilers, optimisers and OSes that