mirror/ioccc
1
0 Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Fixes in html files in 1986/marshall

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

I also threw in a slight formatting change in the thanks file.
This commit is contained in:
Cody Boone Ferguson committed 2024-11-04 06:27:23 -08:00
1 parent 75a993e0cd
commit 5931934d8c
6 files changed
+122 -104
Download Patch File Download Diff File Expand all files Collapse all files

No files matched your search

1986/marshall/README.md
+17 -14
View File
@@ -8,12 +8,12 @@
compilers and systems. See below and [compilers.html](compilers.html) for details. compilers and systems. See below and [compilers.html](compilers.html) for details.
There is an [alternate version](#alternate-code). The reason is a funny problem: There is an [alternate version](#alternate-code). The reason is a funny problem:
in modern systems, depending on the platform, compiler and the optimiser, it in modern systems, depending on the platform, compiler and whether or not the
would work with one compiler with the optimiser but it would not work with the optimiser is enabled, it might work with one compiler but non the other. But
other; and if the optimiser state is changed the previous problematic compiler then if you swap the optimiser state the compiler that worked would no longer
might work but the other one would not. We describe this in more detail in work and the compiler that did not work would. We describe this in more detail
[compilers.html](compilers.html) and we encourage you to read it for entertainment in [compilers.html](compilers.html) and we encourage you to read it for
if nothing else. entertainment if nothing else.
## To use: ## To use:
@@ -26,15 +26,16 @@ if nothing else.
## Alternate code: ## Alternate code:
Due to the different [conflicting problems](compilers.html) with `gcc` and Due to the different [conflicting problems](compilers.html) with `gcc` and
`clang`, we `clang`, we offer the problematic code as an alternate version whereas
instead offer the problematic code as an alternate version whereas [marshall.c](%%REPO_URL%%/1986/marshall/marshall.c) has both the loop (that
[marshall.c](%%REPO_URL%%/1986/marshall/marshall.c) has both the infinite loop and the complicated arg to turned into an infinite loop) commented out and the complicated arg to `_exit(2)`
`_exit()` commented out, changing the value passed into `_exit()` to `1`. commented out, changing the value passed into `_exit()` to `1`.
### Alternate build: ### Alternate build:
To see if your compiler has the problems noted: To see if your compiler has the problems noted above and in
[compilers.html](compilers.html), first build the alternate code:
``` <!---sh--> ``` <!---sh-->
@@ -44,13 +45,15 @@ To see if your compiler has the problems noted:
### Alternate use: ### Alternate use:
Once the alternate code is built, see if your compiler has the problem:
``` <!---sh--> ``` <!---sh-->
./marshall.alt ./marshall.alt
``` ```
Does it work in your system? That is does it not segfault, does it print it only Does it work in your system? That is does it print the text only once and does
once and does it not enter an infinite loop? Or more generally does it print the it not enter an infinite loop? In other words, does it print the text _exactly
text exactly once and then exit? once_ and then exit, without dumping core?
## Judges' remarks: ## Judges' remarks:
1986/marshall/compilers.html
+41 -37
View File
@@ -426,63 +426,67 @@
<!-- BEFORE: 1st line of markdown file: 1986/marshall/compilers.md --> <!-- 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> <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 <p>As briefly noted in the <a href="index.html">index.html</a> <code>gcc</code> versus <code>clang</code> caused
problems with this entry depending on the optimiser being enabled or not, where different problems with this entry, depending on the optimiser being enabled or
if the optimiser was enabled it would work with one compiler and not the other. disabled, where if the optimiser was enabled it would work with one compiler but
But if you then disabled the optimiser the opposite problem would occur: the not the other; on the other hand, if you disabled the optimiser the opposite
working compiler would no longer work and the non-functional one would start to problem would occur: the working compiler would no longer work and the other one
work! And then there’s the problem of linux versus macOS causing problems.</p> would! 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 <p>Using the <a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1986/marshall/marshall.alt.c">alternate source code</a>
you can see if your compiler has the problem as described below.</p> 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) <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 if the optimiser was enabled one compiler would generate code that segfaulted but
the other one would not. However, when then disabling the optimiser the compiler the other one did not. However, when disabling the optimiser, the compiler
that had no problem suddenly did and the one that did suddenly did not. But 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> segfaulting was not by any means the only problem.</p>
<p>Another problem was that depending on the optimiser an infinite loop would be <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 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 <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 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> 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 <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 for <code>clang</code>, which works with some compilers, depending on the optimiser. Below
refer to the code below we refer to the alternate code, we refer to the <a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1986/marshall/marshall.alt.c">alternate code
<a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1986/marshall/marshall.alt.c">marshall.alt.c</a>.</p> marshall.alt.c</a>.</p>
<h2 id="the-conflicting-compiler-problems">The conflicting compiler problems:</h2> <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 <p>Below we describe the conflicting options that resulted in the need to modify
the original code.</p> the original code.</p>
<h3 id="linux">Linux</h3> <h3 id="linux">Linux</h3>
<p>With the optimiser disabled <code>GCC</code> compiled the code to enter an infinite loop. <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 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 <code>clang</code> generates code that first prints the text twice (when it should print it
then immediately dumps core!</p> only once) and then immediately dumps core!</p>
<p>But then there’s that infinite loop. What happens if we remove it?</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 <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 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 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> because of the call to the <code>_exit(2)</code> syscall (see below).</p>
<p><code>Clang</code> works fine with the loop removed and the optimiser disabled. If however we <p><code>clang</code> works fine with the loop removed if the optimiser is disabled. Once we
enable the optimiser <code>clang</code> will generate code that prints the string twice and enable it, though, it will generate code that prints the string twice and
dumps core just like before! What about the call to <code>_exit()</code>?</p> dumps core, just like before!</p>
<p>The call was:</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> <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 <p>In the fixed code, these variables are simply commented out so the code does
disappear!</p> <code>_exit(1)</code>.</p>
<h3 id="macos">macOS</h3> <h3 id="macos">macOS</h3>
<p>But then there was macOS which had another problem!</p> <p>Now as for macOS, <em>another problem</em> existed!</p>
<p>If the infinite loop is not removed/commented out and the optimiser is enabled <p>If the code that resulted in an infinite loop is <em>NOT</em> commented out <em>AND</em> the
it works fine but if it’s disabled it prints out the string and then enters an optimiser is enabled it works fine; but if it [the optimiser] is disabled, it
infinite loop!</p> prints out the string and then enters that infinite loop!</p>
<p>After we fix the infinite loop if we change the <code>_exit()</code> call in macOS and <p>After we fix the infinite loop issue, if we change the call to the <code>_exit(2)</code>
disable the optimiser we might get something like:</p> syscall in macOS and disable the optimiser we might get something like:</p>
<pre><code> $ ./marshall <pre><code> $ ./marshall
choo choo choo choo
Segmentation fault: 11</code></pre> Segmentation fault: 11</code></pre>
<p>Observe how it doesn’t print it twice. But of course it segfaults so it’s not <p>Observe how it doesn’t print it twice. But of course it segfaults so it’s not
right either.</p> right either.</p>
<p>If the optimiser is enabled, however, we will see that it works fine before the <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> <h2 id="summary">Summary</h2>
<p>And that is the tale of a little <del>engine</del> train that <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 could…eventually! Or perhaps it’s the compilers, optimisers and OSes that
1986/marshall/compilers.md
+46 -37
View File
@@ -1,33 +1,35 @@
# Conflicting compilers and optimisers that broke this entry in 2023 # Conflicting compilers and optimisers that broke this entry in 2023
As briefly noted in the [index.html](index.html) `gcc` and `clang` caused different As briefly noted in the [index.html](index.html) `gcc` versus `clang` caused
problems with this entry depending on the optimiser being enabled or not, where different problems with this entry, depending on the optimiser being enabled or
if the optimiser was enabled it would work with one compiler and not the other. disabled, where if the optimiser was enabled it would work with one compiler but
But if you then disabled the optimiser the opposite problem would occur: the not the other; on the other hand, if you disabled the optimiser the opposite
working compiler would no longer work and the non-functional one would start to problem would occur: the working compiler would no longer work and the other one
work! And then there's the problem of linux versus macOS causing problems. would! And then there's the problem of linux versus macOS causing problems.
The [alternate code](%%REPO_URL%%/1986/marshall/marshall.alt.c) (source code) demonstrates the problem so Using the [alternate source code](%%REPO_URL%%/1986/marshall/marshall.alt.c)
you can see if your compiler has the problem as described below. demonstrates the problem so you can see if your compiler has the problem
described below.
In some versions of `gcc` and `clang` (this was first discovered in fedora linux 38) In some versions of `gcc` and `clang` (this was first discovered in fedora linux 38)
if the compiler was enabled one compiler would generate code that segfaulted but if the optimiser was enabled one compiler would generate code that segfaulted but
the other one would not. However, when then disabling the optimiser the compiler the other one did not. However, when disabling the optimiser, the compiler
that had no problem suddenly did and the one that did suddenly did not. But that had no problem suddenly _did_ and the one that did suddenly _did not_. But
segfaulting was not by any means the only problem. segfaulting was not by any means the only problem.
Another problem was that depending on the optimiser an infinite loop would be 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 entered. But then removing it would cause other problems as well, including a
segfault. segfault!
It was not only one compiler that dumped core. Both dumped core with other 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 behaviour, depending on what changes in code were made, and the optimiser being
on or off. `Clang` in macOS also dumped core! on or off. `clang` in macOS also dumped core!
The [marshall.c](%%REPO_URL%%/1986/marshall/marshall.c) has the original fix The [marshall.c](%%REPO_URL%%/1986/marshall/marshall.c) has the original fix
for `clang` which works with some compilers depending on the optimiser. When we for `clang`, which works with some compilers, depending on the optimiser. Below
refer to the code below we refer to the alternate code, we refer to the [alternate code
[marshall.alt.c](%%REPO_URL%%/1986/marshall/marshall.alt.c). marshall.alt.c](%%REPO_URL%%/1986/marshall/marshall.alt.c).
## The conflicting compiler problems: ## The conflicting compiler problems:
@@ -36,42 +38,48 @@ the original code.
### Linux ### Linux
With the optimiser disabled `GCC` compiled the code to enter an infinite loop. With the optimiser disabled `gcc` compiled the code to enter an infinite loop.
If the optimiser was enabled it worked fine. But if the optimiser is enabled If the optimiser was enabled it worked fine, but if the optimiser is enabled
`clang` generates code that first prints the text twice (it should print it once) and `clang` generates code that first prints the text twice (when it should print it
then immediately dumps core! only once) and then immediately dumps core!
But then there's that infinite loop. What happens if we remove it? But then there's that infinite loop. What happens if we fix it?
Once the loop is removed if we compile with `clang` and the optimiser is disabled Once the loop is removed, if we compile with `clang` and the optimiser is disabled
all is okay. If however we compile with `gcc` and the optimiser is disabled the all is okay. If however we compile with `gcc` and the optimiser is disabled the
string is printed once and then the program dumps core! Why is this? It is string is printed once and then the program dumps core! Why is this? It is
because of the call to `_exit()` (see below). because of the call to the `_exit(2)` syscall (see below).
`Clang` works fine with the loop removed and the optimiser disabled. If however we `clang` works fine with the loop removed if the optimiser is disabled. Once we
enable the optimiser `clang` will generate code that prints the string twice and enable it, though, it will generate code that prints the string twice and
dumps core just like before! What about the call to `_exit()`? dumps core, just like before!
The call was:
<div id="exit">
### What about the call to the `_exit(2)` syscall?
</div>
The call _was_:
``` <!---c--> ``` <!---c-->
_exit(argv[(int)*argc-2/cc[1*(int)*argc]|-1<<4]); _exit(argv[(int)*argc-2/cc[1*(int)*argc]|-1<<4]);
``` ```
Changing it to not refer to these variables and just exit 1 and the problems In the fixed code, these variables are simply commented out so the code does
disappear! `_exit(1)`.
### macOS ### macOS
But then there was macOS which had another problem! Now as for macOS, _another problem_ existed!
If the infinite loop is not removed/commented out and the optimiser is enabled If the code that resulted in an infinite loop is _NOT_ commented out _AND_ the
it works fine but if it's disabled it prints out the string and then enters an optimiser is enabled it works fine; but if it [the optimiser] is disabled, it
infinite loop! prints out the string and then enters that infinite loop!
After we fix the infinite loop if we change the `_exit()` call in macOS and After we fix the infinite loop issue, if we change the call to the `_exit(2)`
disable the optimiser we might get something like: syscall in macOS and disable the optimiser we might get something like:
``` <!---sh--> ``` <!---sh-->
$ ./marshall $ ./marshall
@@ -83,7 +91,8 @@ Observe how it doesn't print it twice. But of course it segfaults so it's not
right either. right either.
If the optimiser is enabled, however, we will see that it works fine before the If the optimiser is enabled, however, we will see that it works fine before the
change to `_exit()`. change to the call to the `_exit(2)` syscall.
## Summary ## Summary
1986/marshall/index.html
+16 -14
View File
@@ -449,28 +449,30 @@ Location: <a href="../../location.html#US">US</a> - <em>United States of America
<p><strong>NOTE</strong>: we <strong>FORCE</strong> disable the optimiser due to a funny problem with different <p><strong>NOTE</strong>: we <strong>FORCE</strong> disable the optimiser due to a funny problem with different
compilers and systems. See below and <a href="compilers.html">compilers.html</a> for details.</p> compilers and systems. See below and <a href="compilers.html">compilers.html</a> for details.</p>
<p>There is an <a href="#alternate-code">alternate version</a>. The reason is a funny problem: <p>There is an <a href="#alternate-code">alternate version</a>. The reason is a funny problem:
in modern systems, depending on the platform, compiler and the optimiser, it in modern systems, depending on the platform, compiler and whether or not the
would work with one compiler with the optimiser but it would not work with the optimiser is enabled, it might work with one compiler but non the other. But
other; and if the optimiser state is changed the previous problematic compiler then if you swap the optimiser state the compiler that worked would no longer
might work but the other one would not. We describe this in more detail in work and the compiler that did not work would. We describe this in more detail
<a href="compilers.html">compilers.html</a> and we encourage you to read it for entertainment in <a href="compilers.html">compilers.html</a> and we encourage you to read it for
if nothing else.</p> entertainment if nothing else.</p>
<h2 id="to-use">To use:</h2> <h2 id="to-use">To use:</h2>
<pre><code> ./marshall</code></pre> <pre><code> ./marshall</code></pre>
<h2 id="alternate-code">Alternate code:</h2> <h2 id="alternate-code">Alternate code:</h2>
<p>Due to the different <a href="compilers.html">conflicting problems</a> with <code>gcc</code> and <p>Due to the different <a href="compilers.html">conflicting problems</a> with <code>gcc</code> and
<code>clang</code>, we <code>clang</code>, we offer the problematic code as an alternate version whereas
instead offer the problematic code as an alternate version whereas <a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1986/marshall/marshall.c">marshall.c</a> has both the loop (that
<a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1986/marshall/marshall.c">marshall.c</a> has both the infinite loop and the complicated arg to turned into an infinite loop) commented out and the complicated arg to <code>_exit(2)</code>
<code>_exit()</code> commented out, changing the value passed into <code>_exit()</code> to <code>1</code>.</p> commented out, changing the value passed into <code>_exit()</code> to <code>1</code>.</p>
<h3 id="alternate-build">Alternate build:</h3> <h3 id="alternate-build">Alternate build:</h3>
<p>To see if your compiler has the problems noted:</p> <p>To see if your compiler has the problems noted above and in
<a href="compilers.html">compilers.html</a>, first build the alternate code:</p>
<pre><code> make alt</code></pre> <pre><code> make alt</code></pre>
<h3 id="alternate-use">Alternate use:</h3> <h3 id="alternate-use">Alternate use:</h3>
<p>Once the alternate code is built, see if your compiler has the problem:</p>
<pre><code> ./marshall.alt</code></pre> <pre><code> ./marshall.alt</code></pre>
<p>Does it work in your system? That is does it not segfault, does it print it only <p>Does it work in your system? That is does it print the text only once and does
once and does it not enter an infinite loop? Or more generally does it print the it not enter an infinite loop? In other words, does it print the text <em>exactly
text exactly once and then exit?</p> once</em> and then exit, without dumping core?</p>
<h2 id="judges-remarks">Judges’ remarks:</h2> <h2 id="judges-remarks">Judges’ remarks:</h2>
<p>This program prints the name of the picture. The layout is somewhat <p>This program prints the name of the picture. The layout is somewhat
pretty though it is not the usual sort of output one would expect pretty though it is not the usual sort of output one would expect
thanks-for-help.html
+1 -1
View File
@@ -5171,7 +5171,7 @@ helped improve the presentation of their fellow IOCCC entries.</p>
Ferguson</a> who is responsible for many Ferguson</a> who is responsible for many
improvements and fixes, including entries that no longer worked improvements and fixes, including entries that no longer worked
and other important fixes, often <strong>EXTREMELY HARD</strong> (for certain and other important fixes, often <strong>EXTREMELY HARD</strong> (for certain
definitions of ‘<em>HARD</em>’ :-) ), such as definitions of ‘<code>HARD</code>’ :-) ), such as
<a href="thanks-for-help.html#1988_phillipps">1988/phillipps</a>, <a href="thanks-for-help.html#1988_phillipps">1988/phillipps</a>,
<a href="thanks-for-help.html#1992_vern">1992/vern</a>, <a href="thanks-for-help.html#1992_vern">1992/vern</a>,
<a href="thanks-for-help.html#2001_anonymous">2001/anonymous</a>, <a href="thanks-for-help.html#2001_anonymous">2001/anonymous</a>,
thanks-for-help.md
+1 -1
View File
@@ -7109,7 +7109,7 @@ We call out the extensive contributions of [Cody Boone
Ferguson](authors.html#Cody_Boone_Ferguson) who is responsible for many Ferguson](authors.html#Cody_Boone_Ferguson) who is responsible for many
improvements and fixes, including entries that no longer worked improvements and fixes, including entries that no longer worked
and other important fixes, often **EXTREMELY HARD** (for certain and other important fixes, often **EXTREMELY HARD** (for certain
definitions of '_HARD_' :-) ), such as definitions of '`HARD`' :-) ), such as
[1988/phillipps](thanks-for-help.html#1988_phillipps), [1988/phillipps](thanks-for-help.html#1988_phillipps),
[1992/vern](thanks-for-help.html#1992_vern), [1992/vern](thanks-for-help.html#1992_vern),
[2001/anonymous](thanks-for-help.html#2001_anonymous), [2001/anonymous](thanks-for-help.html#2001_anonymous),