Add alt versions to 1994/schnitzi

The first version uses fgets(3). This version will compile (note that it
does not compile right away: one has to make other adjustments; it is
not a matter of just changing the code to use fgets()!) but when fed its
own source code it will not generate code that can be compiled let alone
use fgets(3).

The second version, schnitzi.alt2.c, has an increased buffer size but it
will not generate code with the same buffer size; rather the size will
be the original. I explain this in detail (did this quite some time
back) in the bugs.md file. I noticed today that the author gives quite
some details too which will be something I can look at later on. Right
now it's more important to get the website in order so that the next
contest can run! I will only look at this later on or else at a time
where I am unable to do the more important work but am able to do this
(though I don't know about that happening it is still something that
theoretically could happen).

The alt code already existed but it was changed to the second version as
the goal is to get it to use fgets(3) regardless of the buffer size.

Note that the other functionality of both alt versions is not affected.

More updates to bugs.md for this and the thanks file has had the entry
added to it (which should have been done earlier on but was neglected
due to the way it came about, the alt code).
This commit is contained in:
Cody Boone Ferguson committed 2023-11-02 04:49:42 -07:00
1 parent b49f5b7352
commit dc34871805
7 files changed
+169 -25

No files matched your search

+3
View File
@@ -1,4 +1,7 @@
schnitzi
schnitzi2
schnitzi2.c
schnitzi.alt
schnitzi.alt2
schnitzi.orig
prog.orig
+13 -1
View File
@@ -130,7 +130,9 @@ all: data ${TARGET}
sandwich supernova deep_magic magic charon pluto
${PROG}: ${PROG}.c
@echo "NOTE: the buffer size of this entry is very small at 100."
${CC} ${CFLAGS} $< -o $@ ${LDFLAGS}
${PROG}2: ${PROG}2.c
${CC} ${CFLAGS} $< -o $@ ${LDFLAGS}
# alternative executable
@@ -138,6 +140,16 @@ ${PROG}: ${PROG}.c
alt: data ${ALT_TARGET}
@${TRUE}
${PROG}.alt: ${PROG}.alt.c
@echo "NOTE: this version has fgets() but will not generate code that can be compiled."
@echo "Other functionality is not affected."
${CC} ${CFLAGS} $< -o $@ ${LDFLAGS}
${PROG}.alt2: ${PROG}.alt2.c
@echo "NOTE: this version has an increased buffer size and will generate code that can"
@echo "compile but the buffer size is not increased. Other functionality is unaffected."
${CC} ${CFLAGS} $< -o $@ ${LDFLAGS}
# data files
#
data: ${DATA}
+31 -11
View File
@@ -1,9 +1,6 @@
# Best Layout
Mark Schnitzius\
ISX Corporation\
1165 Northchase Pkwy, Suite 120\
Marietta, GA 30067\
US\
<http://computronium.org/ioccc.html>
@@ -14,6 +11,11 @@ US\
make all
```
There are two alternate versions, one that has an increased buffer size and one
that uses `fgets()`; neither are completely functional.
See below section bugs and (mis)features for details and the [alternate
code](#alternate-code) section for how to use.
### Bugs and (Mis)features
@@ -36,20 +38,37 @@ For more detailed information see [1994 schnitzi in bugs.md](/bugs.md#1994-schni
## Try:
```sh
./schnitzi < /etc/motd
./schnitzi < /etc/passwd
./schnitzi < /etc/motd 2>/dev/null
./schnitzi < /etc/passwd 2>/dev/null
./schnitzi < schnitzi.c > schnitzi2.c 2>/dev/null
make schnitzi2
./schnitzi2 < README.md
```
## Alternate code:
To build the alternative code try:
The first version, `schnitzi.alt.c`, uses `fgets(3)` but when fed its own code
it will generate code that still uses `gets(3)`. What's more is it will not
compile. Other functionality works fine.
The second version, `schnitzi.alt2.c`, has an increased buffer size but when fed
its own source code it will generate code that can compile but with the original
buffer size. This is due to a comment which is explained in more detail in
[1994/schnitzi in bugs.md](/bugs.md#1994-schnitzi).
### Alternate build:
```sh
make alt
```
Use `schnitzi.alt` as you would `schnitzi`.
### Alternate use:
Use `schnitzi.alt` and `schnitzi.alt2` as you would `schnitzi` above except that
feeding the source code to it will not work right.
## Judges' remarks:
@@ -66,6 +85,7 @@ find out why?
## Author's remarks:
### SPOILER:
This is a program which takes any text file as input and 'flips'
@@ -83,7 +103,7 @@ schnitzi < info
The program generates interesting results when its source file is
used as input:
\
```sh
schnitzi < schnitzi.c
```
@@ -94,11 +114,11 @@ 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\
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\
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\
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.
+4 -4
View File
@@ -20,12 +20,12 @@ h mh111 de{l) +di (+'( d+% c n+
*/ n = 0 ;
main ( ) {
char v [
10000 ] , s;
int t[100 ] ,
u[100 ] ; u
1000 ] , s;
int t[100 ] ,
u[100 ] ; u
[ 0
]=ftell(stdin ) ;
while(gets (v ) )
while(fgets(v,100,stdin )&&((v[strlen(v)-1]='\0',1)) )
{t [ r ]=
strlen (
v);y=
+52
View File
@@ -0,0 +1,52 @@
#include <stdio.h>
int r=0,x,y=0, /*
nt /
c
lx /\ / \ /|\ /|\
u, \/ \\/ \-/ \ /
dn ]
e= ||| /|\ /\ /\ = p p
0 \/ \ / ||| \/ f f f r r
<, tw t s s i i
sy || /|\ /\ i eh e e c n n
t= /- \ / ||| n li l e a t t
d0 ||| t ll l {< k n f f
i, || /|\ /|\ (e s ( fr ( f ( (
o _ ||\ \ / \-/ tu s( t usw o; i s ( " "
. || - / c [[ tg rv [th rx=f t " % \
h mh111 de{l) +di (+'( d+% c n+
> aa000 itte; > +il x+ n inc " "+
/ ir000[ns[nytyrrne<=)'<xn," , );
*/ n = 0 ;
main ( ) {
char v [
10000 ] , s;
int t[100 ] ,
u[100 ] ; u
[ 0
]=ftell(stdin ) ;
while(gets (v ) )
{t [ r ]=
strlen (
v);y=
t[ r ]
>y ? t [
r ] : y;
u[++r ] =
ftell(stdin ) ; }
while ( n
< y )
{for(x=0 ; x
<r;x++) { s
=' ' ;
if(n< t [
x ] ) {
fseek(stdin ,u [ x ]
+n , 0 ) ;
scanf("%c", &
s )
; }
printf("%c", s )
; }
printf("\n"); n
++ ; } }
+48 -9
View File
@@ -875,21 +875,60 @@ one liner it's already quite long.
### Source code: [1994/schnitzi/schnitzi.c](1994/schnitzi/schnitzi.c)
### Information: [1994/schnitzi/README.md](1994/schnitzi/README.md)
The buffer size of this entry is 100 which is very easily overflowed
with `gets()` which it uses. Changing it to use `fgets()` is difficult. Even
changing the buffer size can cause compilation errors and even when that is
fixed it will not translate to the generated file. The buffer size was changed
but to make it the same functionality it was changed back.
NOTE: the generated code of all versions, when fed its own source, will differ
even when it works. See the author's remarks in the README.md for details.
Increasing the buffer size and having it, when fed its own source code,
generate code that will compile with the same buffer size is difficult: it just
uses the original size. Cody explains this further down.
Getting it to use `fgets()` is even harder as when fed its own code it will
generate code that cannot even compile let alone use `fgets(3)`.
In both cases, changing the buffer size and changing it to use `fgets(3)`, will
cause compilation errors without other adjustments.
See the below magic for details. Along with the author's remarks in the
README.md file it might prove possible to get it to use `fgets(3)`. Cody,
writing this on 02 November 2023, only just noticed the author's remarks and
will later on look at this if nobody takes up the challenge. More important work
like getting to a place that the next contest can run must be done first.
[Cody Boone Ferguson](/winners.html#Cody_Boone_Ferguson) explains the magic of
how this entry works which will be necessary if this entry is to be fixed, below.
how this entry works, which will be necessary if this entry is to be fixed,
below.
You might wish to run the command:
```sh
make diff_orig_prog
```
to see what had to change for the buffer size, when looking at the below.
Furthermore you will want to look at:
```sh
diff schnitzi.alt.c schnitzi.alt2.c
```
as the `fgets()` version can compile it just can't generate compilable code (let
alone using `fgets()`) when fed itself (to reiterate, just changing the call to
`fgets(3)` does not mean it can compile and there's a further problem in that
`fgets(3)` retains the newline whereas `gets(3)` does not). Nevertheless looking
at these commands will be of help to understand how it works.
For the alternate versions the other functionality is unaffected.
### The magic of [1994/schnitzi](1994/schnitzi/schnitzi.c) and how it flips text
The problem is getting the generated code to use `fgets()` (once it even
compiles which is easy to do) and also have the updated buffer size be the same.
The generated output, when changed to `fgets()` failed to compile. The buffer
size, when using `gets()` is still the same.
compiles which was easy to do) and also have the updated buffer size be the
same (which was easy to do too at least in the original version). The generated
output, when changed to `fgets()` failed to compile and it also used `gets(3)`
and these are the bugs here.
The buffer size, when using `gets()` is still the same but as noted above the
original code has had a buffer size increase.
The real problem is with formatting the code. 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
+18
View File
@@ -1409,6 +1409,24 @@ program chooses that line it might print the first 231 characters or it might
print (up to) the next 231 characters and so on.
## [1994/schnitzi](1994/schnitzi/schnitzi.c) ([README.md](1994/schnitzi/README.md]))
Cody added two alt versions, [one which uses
`fgets()`](1994/schnitzi/schnitzi.alt.c) but when fed its own source code cannot
generate code that compile and another [one with a bigger buffer
size](1994/schnitzi/schnitzi.alt2.c) which, when fed its own source code, will
generate compilable code but not with the same buffer size but rather the
original buffer size. Cody explains this in the at [1994/schnitzi in
bugs.md](/bugs.md#1994-schnitzi).
The purpose for these versions it both demonstrate how the magic works behind it
and to help others, should they wish to, get the code to work with `fgets(3)`, with
or without an increase in buffer size. See [1994/schnitzi in
bugs.md](/bugs.md#1994-schnitzi) where Cody also explains the magic for more
details. Later on, if nobody takes up the task, Cody might resume it, but for
now there is more important work to do so that the next contest can run.
## [1994/shapiro](1994/shapiro/shapiro.c) ([README.md](1994/shapiro/README.md]))
Cody fixed a bug on systems where `EOF != -1`. The problem is that `getc()` and