Merge pull request #1260 from xexyl/1994-schnitzi-alt-codes

Add alt versions to 1994/schnitzi

1994/schnitzi/.gitignore

@@ -1,4 +1,7 @@
 schnitzi
+schnitzi2
+schnitzi2.c
 schnitzi.alt
+schnitzi.alt2
 schnitzi.orig
 prog.orig

1994/schnitzi/Makefile

@@ -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}

1994/schnitzi/README.md

@@ -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/motd 2>/dev/null
-./schnitzi < /etc/passwd
+./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.
 

1994/schnitzi/schnitzi.alt.c

@@ -20,12 +20,12 @@ h                   mh111 de{l)   +di (+'( d+%  c n+
  */                 n         =             0     ;
                main        (       )   {
                 char       v   [
-              10000    ]                   ,  s;
+                1000   ]                   ,  s;
-          int t[100     ]                    ,
+          int t[100    ]                    ,
-              u[100               ]     ;  u
+              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=

1994/schnitzi/schnitzi.alt2.c

@@ -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
+                 ++   ;            }           }

bugs.md

@@ -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
+NOTE: the generated code of all versions, when fed its own source, will differ
-with `gets()` which it uses. Changing it to use `fgets()` is difficult. Even
+even when it works. See the author's remarks in the README.md for details.
-changing the buffer size can cause compilation errors and even when that is
+Increasing the buffer size and having it, when fed its own source code,
-fixed it will not translate to the generated file. The buffer size was changed
+generate code that will compile with the same buffer size is difficult: it just
-but to make it the same functionality it was changed back.
+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.
+compiles which was easy to do) and also have the updated buffer size be the
-The generated output, when changed to `fgets()` failed to compile. The buffer
+same (which was easy to do too at least in the original version). The generated
-size, when using `gets()` is still the same.
+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

thanks-for-fixes.md

@@ -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