Fixes and updates in 1994/schnitzi

Formatting fixes in README.md.  Also refer to bugs.md file where I give
hints on the magic of the entry in order that it can hopefully be made
to use fgets() and have an increased buffer size.

Updated bugs.md about this entry with an important point about the
fgets() / buffer size issue: it can very easily be made to use fgets()
and having an increased buffer size. But the program is supposed to be
able to be fed its own source code and generate output that can do the
same thing and is compilable. Changing the code to use fgets() will
cause compiler errors in the generated output. As well even though I
changed the buffer size it is not generated in the output when feeding
the program its own source code.

In the bugs.md file I also pointed out just how sensitive this program
is (by design): a single space in the wrong place or a single character
in the wrong place can break the program; it's very sensitive.

One should be able to do:

	./schnitzi < schnitzi.c

and compile the generated output. That new program should be able to do
the same thing as well.

1994/schnitzi/README.md

@@ -1,10 +1,10 @@
 # Best Layout:
 
-	Mark Schnitzius
-	ISX Corporation
-	1165 Northchase Pkwy, Suite 120
-	Marietta, GA 30067
-	USA
+Mark Schnitzius
+ISX Corporation
+1165 Northchase Pkwy, Suite 120
+Marietta, GA 30067
+USA
 
 ## To build:
 
@@ -21,8 +21,9 @@ results in compiler errors and not only that but the gets() is still there in
 the generated output. Even changing the buffer size can result in compilation
 errors if not done correctly. The generated output also does not have a changed
 buffer size. Changing it to use fgets() can happen later, maybe, but bigger
-files can now be parsed by the original code. An example is this Makefile. Thank
-you Cody!
+files can now be parsed by the original code. An example is this Makefile. Cody
+gave some tips on how this entry works, in order to make the entry use fgets()
+and compile successfully too, in the [bugs.md](/bugs.md) file. Thank you Cody!
 
 
 ## Try:
@@ -45,50 +46,50 @@ find out why?
 
 ## Author's comments:
 
-    SPOILER:
+### SPOILER:
+
+This is a program which takes any text file as input and 'flips'
+the input file along a diagonal running from the top left corner
+down to the bottom right.  In other words, the first row in the
+file ends up written down the first column of the result, the
+second row is written down the second column, etc. The program
+is run by redirecting a file into the executable on the command
+line; for instance, for the included 'info' file, the program
+would be run as follows:
 
-    This is a program which takes any text file as input and 'flips'
-    the input file along a diagonal running from the top left corner
-    down to the bottom right.  In other words, the first row in the
-    file ends up written down the first column of the result, the
-    second row is written down the second column, etc. The program
-    is run by redirecting a file into the executable on the command
-    line; for instance, for the included 'info' file, the program
-    would be run as follows:
-    
     	schnitzi < info
     
-    The program generates interesting results when its source file is
-    used as input:
+The program generates interesting results when its source file is
+used as input:
     
     	schnitzi < schnitzi.c
     
-    The result of this command is a program which does the exact same
-    thing -- in other words, both the program and the "flipped"
-    version of itself work identically (you'll need to redirect the
-    output of the above command into a separate file and compile it).
-    You might notice some differences in the flipped version, though.
-    First off, a secret message becomes visible that was not visible
-    in the original program.  Also, much of the code shows up in 
-    different places in the flipped program than it appeared in the
-    first program.  My first version of this program was perfectly 
-    symmetrical along the diagonal, but later found out there were
-    interesting ways to break the symmetry.  The best way to see this 
-    is to load both the original and flipped versions of the program
-    into an editor and switch back and forth between them rapidly.
-    
-    C tokens longer than a character (such as "main") proved difficult
-    to use in both the original and flipped versions (after flipping,
-    they show up as a string of single letters on successive lines).
-    However, I found that it was possible to get around this through
-    a few well-placed comments.  An earlier version of this program
-    used nearly every single-character token in the "shared" area;
-    however, it proved to be too large for contest guidelines (although
-    the code itself is only about 300 characters, the extra whitespace
-    needed to pad it put it over the limit -- it nearly filled a 79 by
-    79 area, adding up to over 4000 total characters).  I will provide
-    this other version to anyone interested -- contact me by email
-    at schnitzi@east.isx.com.
+The result of this command is a program which does the exact same
+thing -- in other words, both the program and the "flipped"
+version of itself work identically (you'll need to redirect the
+output of the above command into a separate file and compile it).
+You might notice some differences in the flipped version, though.
+First off, a secret message becomes visible that was not visible
+in the original program.  Also, much of the code shows up in 
+different places in the flipped program than it appeared in the
+first program.  My first version of this program was perfectly 
+symmetrical along the diagonal, but later found out there were
+interesting ways to break the symmetry.  The best way to see this 
+is to load both the original and flipped versions of the program
+into an editor and switch back and forth between them rapidly.
+
+C tokens longer than a character (such as "main") proved difficult
+to use in both the original and flipped versions (after flipping,
+they show up as a string of single letters on successive lines).
+However, I found that it was possible to get around this through
+a few well-placed comments.  An earlier version of this program
+used nearly every single-character token in the "shared" area;
+however, it proved to be too large for contest guidelines (although
+the code itself is only about 300 characters, the extra whitespace
+needed to pad it put it over the limit -- it nearly filled a 79 by
+79 area, adding up to over 4000 total characters).  I will provide
+this other version to anyone interested -- contact me by email
+at schnitzi@east.isx.com.
 
 ## Copyright and CC BY-SA 4.0 License:
 

bugs.md

@@ -481,11 +481,16 @@ generate compiler errors. Cody explains the magic below which might be used to
 change this entry to fgets() (and he'll be working on it in the coming days most
 likely).
 
-### The magic of the entry
+### The magic of [1994/schnitzi](1994/schnitzi/schnitzi.c) and how it flips text
+
+Cody provided some tips in how the entry works so that it can hopefully be made
+to use fgets() and also hopefully have the buffer size updated in the generated
+code. He notes that this might be a real problem with formatting the code but
+nevertheless he offers the below tips:
 
 Take a look at the interesting comment as well as the `int r=0,x,y=0` at the top
 of the file. If you look at each column go down that column you can see how it
-spells out the code. For instance the first column looks like:
+spells out the code! For instance the first column looks like:
 
 
 ```
@@ -525,6 +530,26 @@ provide the correct input in comments or possibly by rearranging some of the
 code (this was required to make the generated code compile at all when changing
 the buffer size).
 
+### Important points:
+
+Getting this entry to use `fgets()` is easy but the problem is you're supposed
+to be able to feed the source to the program and the output of that will be
+compilable. It however will create compiler errors. So it's not just changing
+the code to get it to use fgets()! I (Cody) already did this before I noticed
+the other part which is why I rolled that part back. I did increase the buffer
+size but that only works on the original source.
+
+To say just how sensitive this entry is: even a space, lack of space or a
+character, wrong character, lack of character or character in the wrong place
+can cause a compilation error! Make sure that the output of:
+
+```sh
+./schnitzi < schnitzi.c
+```
+
+can be compiled and the output of that new program when fed itself can also be
+compiled!
+
 
 # 1995