From 5931934d8cd7dc45078a0efa6ea0f3ab6308eaf2 Mon Sep 17 00:00:00 2001 From: Cody Boone Ferguson <53008573+xexyl@users.noreply.github.com> Date: Mon, 4 Nov 2024 06:27:23 -0800 Subject: [PATCH] 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/README.md | 31 ++++++++------ 1986/marshall/compilers.html | 78 +++++++++++++++++---------------- 1986/marshall/compilers.md | 83 ++++++++++++++++++++---------------- 1986/marshall/index.html | 30 +++++++------ thanks-for-help.html | 2 +- thanks-for-help.md | 2 +- 6 files changed, 122 insertions(+), 104 deletions(-) diff --git a/1986/marshall/README.md b/1986/marshall/README.md index cdea38b38..067222bed 100644 --- a/1986/marshall/README.md +++ b/1986/marshall/README.md @@ -8,12 +8,12 @@ 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: -in modern systems, depending on the platform, compiler and the optimiser, it -would work with one compiler with the optimiser but it would not work with the -other; and if the optimiser state is changed the previous problematic compiler -might work but the other one would not. We describe this in more detail in -[compilers.html](compilers.html) and we encourage you to read it for entertainment -if nothing else. +in modern systems, depending on the platform, compiler and whether or not the +optimiser is enabled, it might work with one compiler but non the other. But +then if you swap the optimiser state the compiler that worked would no longer +work and the compiler that did not work would. We describe this in more detail +in [compilers.html](compilers.html) and we encourage you to read it for +entertainment if nothing else. ## To use: @@ -26,15 +26,16 @@ if nothing else. ## Alternate code: Due to the different [conflicting problems](compilers.html) with `gcc` and -`clang`, we -instead offer the problematic code as an alternate version whereas -[marshall.c](%%REPO_URL%%/1986/marshall/marshall.c) has both the infinite loop and the complicated arg to -`_exit()` commented out, changing the value passed into `_exit()` to `1`. +`clang`, we offer the problematic code as an alternate version whereas +[marshall.c](%%REPO_URL%%/1986/marshall/marshall.c) has both the loop (that +turned into an infinite loop) commented out and the complicated arg to `_exit(2)` +commented out, changing the value passed into `_exit()` to `1`. ### 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: ``` @@ -44,13 +45,15 @@ To see if your compiler has the problems noted: ### Alternate use: +Once the alternate code is built, see if your compiler has the problem: + ``` ./marshall.alt ``` -Does it work in your system? That is does it not segfault, does it print it only -once and does it not enter an infinite loop? Or more generally does it print the -text exactly once and then exit? +Does it work in your system? That is does it print the text only once and does +it not enter an infinite loop? In other words, does it print the text _exactly +once_ and then exit, without dumping core? ## Judges' remarks: diff --git a/1986/marshall/compilers.html b/1986/marshall/compilers.html index 02d7d8bcc..73ef40676 100644 --- a/1986/marshall/compilers.html +++ b/1986/marshall/compilers.html @@ -426,63 +426,67 @@

Conflicting compilers and optimisers that broke this entry in 2023

-

As briefly noted in the index.html gcc and clang 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.

-

The alternate code (source code) demonstrates the problem so -you can see if your compiler has the problem as described below.

+

As briefly noted in the index.html gcc versus clang 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.

+

Using the alternate source code +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) -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 did and the one that did suddenly did not. But segfaulting was not by any means the only problem.

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.

+segfault!

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. Clang in macOS also dumped core!

+behaviour, depending on what changes in code were made, and the optimiser being +on or off. clang in macOS also dumped core!

The marshall.c has the original fix -for clang which works with some compilers depending on the optimiser. When we -refer to the code below we refer to the alternate code, -marshall.alt.c.

+for clang, which works with some compilers, depending on the optimiser. Below +we refer to the alternate code +marshall.alt.c.

The conflicting compiler problems:

Below we describe the conflicting options that resulted in the need to modify the original code.

Linux

-

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 -clang generates code that first prints the text twice (it should print it once) and -then immediately dumps core!

-

But then there’s that infinite loop. What happens if we remove it?

-

Once the loop is removed if we compile with clang and the optimiser is disabled +

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 +clang generates code that first prints the text twice (when it should print it +only once) and then immediately dumps core!

+

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 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 -because of the call to _exit() (see below).

-

Clang works fine with the loop removed and the optimiser disabled. If however we -enable the optimiser clang will generate code that prints the string twice and -dumps core just like before! What about the call to _exit()?

-

The call was:

+because of the call to the _exit(2) syscall (see below).

+

clang 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!

+
+

What about the call to the _exit(2) syscall?

+
+

The call was:

    _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 -disappear!

+

In the fixed code, these variables are simply commented out so the code does +_exit(1).

macOS

-

But then there was macOS which had another problem!

-

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!

-

After we fix the infinite loop if we change the _exit() call in macOS and -disable the optimiser we might get something like:

+

Now as for macOS, another problem existed!

+

If the code that resulted in an infinite loop is NOT commented out AND 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!

+

After we fix the infinite loop issue, if we change the call to the _exit(2) +syscall in macOS and disable the optimiser we might get something like:

    $ ./marshall
           choo choo
     Segmentation fault: 11

Observe how it doesn’t print it twice. But of course it segfaults so it’s not right either.

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

And that is the tale of a little engine train that could…eventually! Or perhaps it’s the compilers, optimisers and OSes that diff --git a/1986/marshall/compilers.md b/1986/marshall/compilers.md index cd6b75069..c2ab59001 100644 --- a/1986/marshall/compilers.md +++ b/1986/marshall/compilers.md @@ -1,33 +1,35 @@ # Conflicting compilers and optimisers that broke this entry in 2023 -As briefly noted in the [index.html](index.html) `gcc` and `clang` 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. +As briefly noted in the [index.html](index.html) `gcc` versus `clang` 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. -The [alternate code](%%REPO_URL%%/1986/marshall/marshall.alt.c) (source code) demonstrates the problem so -you can see if your compiler has the problem as described below. +Using the [alternate source code](%%REPO_URL%%/1986/marshall/marshall.alt.c) +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) -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 _did_ and the one that did suddenly _did not_. But segfaulting was not by any means the only problem. 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. +segfault! 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. `Clang` in macOS also dumped core! +behaviour, depending on what changes in code were made, and the optimiser being +on or off. `clang` in macOS also dumped core! 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 -refer to the code below we refer to the alternate code, -[marshall.alt.c](%%REPO_URL%%/1986/marshall/marshall.alt.c). +for `clang`, which works with some compilers, depending on the optimiser. Below +we refer to the [alternate code +marshall.alt.c](%%REPO_URL%%/1986/marshall/marshall.alt.c). + ## The conflicting compiler problems: @@ -36,42 +38,48 @@ the original code. ### Linux -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 -`clang` generates code that first prints the text twice (it should print it once) and -then immediately dumps core! +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 +`clang` generates code that first prints the text twice (when it should print it +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 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 -enable the optimiser `clang` will generate code that prints the string twice and -dumps core just like before! What about the call to `_exit()`? +`clang` 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! -The call was: + +

+### What about the call to the `_exit(2)` syscall? +
+ +The call _was_: ``` _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 -disappear! +In the fixed code, these variables are simply commented out so the code does +`_exit(1)`. + ### 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 -it works fine but if it's disabled it prints out the string and then enters an -infinite loop! +If the code that resulted in an infinite loop is _NOT_ commented out _AND_ 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! -After we fix the infinite loop if we change the `_exit()` call in macOS and -disable the optimiser we might get something like: +After we fix the infinite loop issue, if we change the call to the `_exit(2)` +syscall in macOS and disable the optimiser we might get something like: ``` $ ./marshall @@ -83,7 +91,8 @@ Observe how it doesn't print it twice. But of course it segfaults so it's not right either. 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 diff --git a/1986/marshall/index.html b/1986/marshall/index.html index b7b6d0196..889bc4d13 100644 --- a/1986/marshall/index.html +++ b/1986/marshall/index.html @@ -449,28 +449,30 @@ Location: US - United States of America

NOTE: we FORCE disable the optimiser due to a funny problem with different compilers and systems. See below and compilers.html for details.

There is an alternate version. The reason is a funny problem: -in modern systems, depending on the platform, compiler and the optimiser, it -would work with one compiler with the optimiser but it would not work with the -other; and if the optimiser state is changed the previous problematic compiler -might work but the other one would not. We describe this in more detail in -compilers.html and we encourage you to read it for entertainment -if nothing else.

+in modern systems, depending on the platform, compiler and whether or not the +optimiser is enabled, it might work with one compiler but non the other. But +then if you swap the optimiser state the compiler that worked would no longer +work and the compiler that did not work would. We describe this in more detail +in compilers.html and we encourage you to read it for +entertainment if nothing else.

To use:

    ./marshall

Alternate code:

Due to the different conflicting problems with gcc and -clang, we -instead offer the problematic code as an alternate version whereas -marshall.c has both the infinite loop and the complicated arg to -_exit() commented out, changing the value passed into _exit() to 1.

+clang, we offer the problematic code as an alternate version whereas +marshall.c has both the loop (that +turned into an infinite loop) commented out and the complicated arg to _exit(2) +commented out, changing the value passed into _exit() to 1.

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, first build the alternate code:

    make alt

Alternate use:

+

Once the alternate code is built, see if your compiler has the problem:

    ./marshall.alt
-

Does it work in your system? That is does it not segfault, does it print it only -once and does it not enter an infinite loop? Or more generally does it print the -text exactly once and then exit?

+

Does it work in your system? That is does it print the text only once and does +it not enter an infinite loop? In other words, does it print the text exactly +once and then exit, without dumping core?

Judges’ remarks:

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 diff --git a/thanks-for-help.html b/thanks-for-help.html index 05cd74816..19bb79c28 100644 --- a/thanks-for-help.html +++ b/thanks-for-help.html @@ -5171,7 +5171,7 @@ helped improve the presentation of their fellow IOCCC entries.

Ferguson who is responsible for many improvements and fixes, including entries that no longer worked and other important fixes, often EXTREMELY HARD (for certain -definitions of ‘HARD’ :-) ), such as +definitions of ‘HARD’ :-) ), such as 1988/phillipps, 1992/vern, 2001/anonymous, diff --git a/thanks-for-help.md b/thanks-for-help.md index 5d58312e5..923eed933 100644 --- a/thanks-for-help.md +++ b/thanks-for-help.md @@ -7109,7 +7109,7 @@ We call out the extensive contributions of [Cody Boone Ferguson](authors.html#Cody_Boone_Ferguson) who is responsible for many improvements and fixes, including entries that no longer worked 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), [1992/vern](thanks-for-help.html#1992_vern), [2001/anonymous](thanks-for-help.html#2001_anonymous),