Merge pull request #1084 from xexyl/1986-pawka

1986/applin/README.md

@@ -1,7 +1,7 @@
 # Most adaptable program
 
-Jack Applin    
+Jack Applin<br>
-US   
+US<br>
 <https://www.cs.colostate.edu/~applin/>
 
 ## To build:

1986/august/README.md

@@ -1,6 +1,6 @@
 # Best complex task done in a complex way
 
-Lennart Augustsson   
+Lennart Augustsson<br>
 <https://web.archive.org/web/20090831055828/http://www.cs.chalmers.se/~augustss>
 
 ## To build:
@@ -15,13 +15,12 @@ make all
 ./august
 ```
 
-
 NOTE: this entry is very likely to core dump after its output.
 
 ## Judges' remarks:
 
 This program computes a specific mathematical value.  Simply compile
-and give it an infinite amount of stack space and cpu time.  Otherwise
+and give it an infinite amount of stack space and CPU time.  Otherwise
 just be satisfied with the approximation displayed just before the core
 dump.
 

1986/bright/README.md

@@ -1,6 +1,6 @@
 # Most useful obfuscation 
 
-Walter Bright  
+Walter Bright
 
 ## To build:
 

1986/hague/README.md

@@ -1,6 +1,6 @@
 # Worst abuse of the C preprocessor
 
-Jim Hague    
+Jim Hague<br>
 UK  
 
 ## To build:
@@ -62,7 +62,7 @@ others.
 
 This program was selected for the 1987 t-shirt collection.
 
-Think Morse code when you ponder this program.  Note how use of
+Think Morse code when you ponder this program.  Note how the use of
 similar variables can be obfuscating!  The author noted that this
 program implements the international Morse standard.  Now for extra
 credit, what Morse message does the program spell out?

1986/holloway/README.md

@@ -1,6 +1,6 @@
 # Best simple task performed in a complex way
 
-Bruce Holloway  
+Bruce Holloway<br>
 US  
 
 ## To build:

1986/marshall/README.md

@@ -8,12 +8,13 @@ Eric Marshall
 make all
 ```
 
-There is an alternate version. See the Alternate code section for the commentary
+There is an alternate version. See the [Alternate code](#alternate-code) section
-on why this is: there was a funny problem in modern systems where depending on
+for the commentary on why this is: there was a funny problem in modern systems
-the compiler and flags it would work with one compiler with the optimiser but it
+where depending on the compiler and the optimiser it would work with one
-would not work with the other; and if the optimiser state is changed the
+compiler with the optimiser but it would not work with the other; and if the
-previous problematic compiler might work but the other one would not! We
+optimiser state is changed the previous problematic compiler might work but the
-describe this in more detail below and we encourage you to read it.
+other one would not. We describe this in more detail below and we encourage you
+to read it for entertainment if nothing else.
 
 
 ## Try:
@@ -29,36 +30,37 @@ options briefly noted above we provide the code that demonstrates the problem so
 you can see if your compiler has the problem as described below.
 
 In some versions of gcc and clang (this was first discovered in fedora linux 38)
-depending on whether or not the optimiser was enabled would cause one compiler
+if the compiler was enabled one compiler would generate code that segfaulted but
-to generate code that segfaults but not another - but when changing the state
+the other one would not. However, when then disabling the optimiser the compiler
-of the optimiser the opposite would happen: the compiler that did not cause a
+that had no problem suddenly did and the one that did suddenly did not.
-segfault suddenly did and the one that did now worked! Another problem was an
+
-infinite loop also depending on the optimiser.
+Another problem was that depending on the optimiser an infinite loop would be
+entered.
 
 The alternate code 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.
 
-### The conflicting compiler problems:
+#### The conflicting compiler problems:
 
 Below we describe the conflicting options that resulted in the need to modify
 the original code.
 
-#### Linux
+##### Linux
 
 With the optimiser disabled GCC compiled the code to enter an infinite loop.
 Enabling the optimiser and 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 what happens if we remove the infinite loop?
+But then there's that infinite loop. What happens if we remove it?
 
-Once the loop is fixed 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 the program then 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). Clang works fine with the loop
 removed and the optimiser disabled. If however we enable the optimiser clang
-generates code that prints the string twice and dumps core just like before!
+will generate code that prints the string twice and dumps core just like before!
 What about the call to `_exit()`?
 
 The call was:
@@ -71,10 +73,10 @@ _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!
 
-#### macOS
+##### macOS
 
 But as noted just because it works one way in linux does not mean it works the
-same way in macOS!
+same way in macOS.
 
 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
@@ -89,7 +91,8 @@ $ ./marshall
 Segmentation fault: 11
 ```
 
-Observe how it doesn't print it twice.
+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()`.
@@ -97,9 +100,10 @@ change to `_exit()`.
 
 #### To use:
 
-Due to the different conflicting problems we instead offer the problematic code
+Due to the different conflicting problems with gcc and clang, we instead offer
-as an alternate version whereas [marshall.c](marshall.c) has both the infinite
+the problematic code as an alternate version whereas [marshall.c](marshall.c)
-loop and the complicated arg to `_exit()` commented out, replaced by just `1`.
+has both the infinite loop and the complicated arg to `_exit()` commented out,
+changing the value passed into `_exit()` to `1`.
 
 To try out the alternate version:
 

1986/pawka/Makefile

@@ -38,7 +38,8 @@ include ../../var.mk
 
 # Common C compiler warnings to silence
 #
-CSILENCE= -Wno-non-literal-null-conversion -Wno-unused-value
+CSILENCE= -Wno-non-literal-null-conversion -Wno-unused-value -Wno-strict-prototypes \
+	  -Wno-implicit-int
 
 # Common C compiler warning flags
 #
@@ -57,7 +58,7 @@ ARCH=
 
 # Defines that are needed to compile
 #
-CDEFINE= -Wno-strict-prototypes
+CDEFINE=
 
 # Include files that are needed to compile
 #

1986/pawka/README.md

@@ -1,9 +1,7 @@
 # Most illegible code
 
-Michael H. Pawka  
+Michael H. Pawka<br>
-Naval Ocean Systems Center  
+US
-San Diego, Ca  
-92152  
 
 ## To build:
 

1986/stein/README.md

@@ -1,6 +1,6 @@
 # Best one liner 
 
-Jan Stein  
+Jan Stein
 
 ## To build:
 

1986/wall/README.md

@@ -1,6 +1,6 @@
 # Grand prize in most well-rounded in confusion
 
-Larry Wall  
+Larry Wall<br>
 US 
 
 ## To build:
@@ -38,11 +38,12 @@ The original version did not have a ';' character in the first line.
 This caused a number of System V C pre-preprocessors to gripe about a
 syntax error.
 
-This program is a masterpiece of obfuscation and humor.  Larry Wall
+This program is a masterpiece of obfuscation and humor.  Larry Wall (the hacker
-(the hacker who gave us `rn` and `patch`) asks you to compile and consider
+who gave us [rn](https://en.wikipedia.org/wiki/Rn_(newsreader)) and
-the warning message generated by the C compiler.  Then execute the
+[patch](https://en.wikipedia.org/wiki/Patch_(Unix))) asks you to compile and
-program and type characters into its standard input.  You will see why
+consider the warning message generated by the C compiler.  Then execute the
-the compiler documents the program.
+program and type characters into its standard input.  You will see why the
+compiler documents the program.
 
 ## Author's remarks:
 

thanks-for-fixes.md

@@ -229,26 +229,30 @@ and gcc.
 
 ## [1986/marshall](1986/marshall/marshall.c) ([README.md](1986/marshall/README.md]))
 
-Cody got this to compile and work with clang and gcc. The optimiser being
+Cody got this to compile and work with clang and gcc. He noted that he tried to
+keep the ASCII art as close to the original as possible. The line lengths are
+the same but some spaces had to be changed to non-spaces.
+
+This fix was very interesting and quite amusing, showing up problems with
+compilers. This is a brief summary but much more is explained in the README.md,
+giving which compilers had which problems in which systems: the optimiser being
 enabled in one compiler let it work but broke it in the other; and disabling it
 would let it work in the one that didn't work but suddenly the one that worked
-would be broken. See below and the README.md file for more details.
+would be broken.
 
 This problem was only after getting clang to compile, of course. It did not
 compile it because it is more strict about the second and third args to `main()`
-and the third arg was an `int`.  Cody notes that he tried to keep the ASCII art
+and the third arg was an `int`.
-as close to the original as possible. The line lengths are the same but some
-spaces had to be changed to non-spaces.
 
-As noted above, a very funny problem occurred depending on the compiler and
+We encourage you to read the README.md file to see how odd this problem was and
-whether or not the optimiser was enabled that had to be fixed: one compiler
-would work fine but another might enter an infinite loop or segfault but then
-once the optimiser state was changed the compiler that worked no longer worked
-(in the same was as the other one not working) and the one that didn't work did!
-
-We encourage you to see the README.md file to see how odd this problem was and
 what Cody did to fix it!
 
+## [1986/pawka](1986/pawka/pawka.c) ([README.md](1986/pawka/README.md))
+
+Cody noticed and fixed a funny mistake in the Makefile where a
+`-Wno-strict-prototypes` was in the wrong location, suggesting that there is a
+`-D` needed to compile the entry.
+
 
 ## [1986/wall](1986/wall/wall.c) ([README.md](1986/wall/README.md]))