Merge pull request #251 from xexyl/1994-schnitzi

Fixes and updates in 1994/schnitzi
This commit is contained in:
Landon Curt Noll authored and GitHub committed 2023-04-02 16:24:14 -07:00
commit 1afd85d2cc
2 files changed
+73 -47

No files matched your search

+46 -45
View File
@@ -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:
+27 -2
View File
@@ -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