From f3d6dc720277a8917fd2b74ca9954d994cf44c41 Mon Sep 17 00:00:00 2001 From: Cody Boone Ferguson <53008573+xexyl@users.noreply.github.com> Date: Sat, 1 Apr 2023 10:23:25 -0700 Subject: [PATCH 1/2] Partially undo 5bbdf55 (1994/schnitzi) The problem with changing it to use fgets() is feeding the program itself generates compiler errors and the generated file does not use fgets() either. This will have to be done another time, maybe. The buffer size was increased to 10000 and even this required some slight changes in formatting in order for the generated output to compile okay. The buffer size generated is still the same as the original but now larger files can be parsed by the original code and everything compiles okay again. --- 1994/schnitzi/README.md | 14 +++++++++----- 1994/schnitzi/schnitzi.c | 8 ++++---- 2 files changed, 13 insertions(+), 9 deletions(-) diff --git a/1994/schnitzi/README.md b/1994/schnitzi/README.md index e7733f2dc..0f45cd400 100644 --- a/1994/schnitzi/README.md +++ b/1994/schnitzi/README.md @@ -14,11 +14,15 @@ ./schnitzi < textfile -[Cody Boone Ferguson](/winners.html#Cody_Boone_Ferguson) fixed the entry to not -overflow the buffer (and segfault) by changing the call of `gets()` to -`fgets()`. He also increased the buffer size. Prior to this fix one could not -redirect the Makefile into this program, as an example problem. Thank you Cody -for your assistance! +[Cody Boone Ferguson](/winners.html#Cody_Boone_Ferguson) increased the buffer +size from 100 to 10000. Changing it to use `fgets()` instead of `gets()` is more +problematic because when feeding the source code to the program the output +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! ## Try: diff --git a/1994/schnitzi/schnitzi.c b/1994/schnitzi/schnitzi.c index 2b1440fd5..a28d79ee9 100644 --- a/1994/schnitzi/schnitzi.c +++ b/1994/schnitzi/schnitzi.c @@ -20,12 +20,12 @@ h mh111 de{l) +di (+'( d+% c n+ */ n = 0 ; main ( ) { char v [ - 1000 ] , s; - int t[100 ] , - u[100 ] ; u + 10000 ] , s; + int t[100 ] , + u[100 ] ; u [ 0 ]=ftell(stdin ) ; - while(fgets(v,100,stdin )&&((v[strlen(v)-1]='\0',1)) ) + while(gets (v ) ) {t [ r ]= strlen ( v);y= From 94907339fc9855b7261448f370a308b557334f55 Mon Sep 17 00:00:00 2001 From: Cody Boone Ferguson <53008573+xexyl@users.noreply.github.com> Date: Sat, 1 Apr 2023 10:59:51 -0700 Subject: [PATCH 2/2] Explain magic of 1994/schnitzi in bugs.md Since the entry cannot yet compile if it's changed to use fgets() I decided to take a look at the source. Quite quickly I noticed something fun at the top. If you look at each column and go down row by row you see it spelling out the code! I wrote the following tips in the bugs.md as an example: 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: i n c l u d e < s t d i o . h > If you join the lines you end up with: #include If you look at column 25 which is the end of the word 'mh111' and you go down to the next row you'll see a 0 and if you go one row down another 0. This is the buffer size, 100, for `u`. The column to the left is the same for the `t` variable. Thus it seems that in order to get the generated output correct one needs to 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). From this it should be possible, theoretically, to come up with the right code so that everything works okay. --- bugs.md | 57 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 57 insertions(+) diff --git a/bugs.md b/bugs.md index 8936638e8..05eddac92 100644 --- a/bugs.md +++ b/bugs.md @@ -453,6 +453,63 @@ this simply does not work with them. Can you help us? # 1994 +## [1994/schnitzi](1994/schnitzi.c) ([README.md])(1994/schnitzi/README.md)) +## STATUS: uses gets() - change to fgets() if possible + +The original buffer size of this entry is 100 which is very easily overflowed +with `gets()` which it uses. [Cody Boone +Ferguson](/winners.html#Cody_Boone_Ferguson) changed the buffer size to 10000 +but he notes a problem in that this does not translate to the generated source +file (when feeding the source itself). With `fgets()` it generates compiler +errors. Without special care with changing the buffer size it would also +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 + +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: + + +``` +i +n +c +l +u +d +e + +< +s +t +d +i +o +. +h +> +``` + +If you join the lines you end up with: + + +```c +#include +``` + +If you look at column 25 which is the end of the word 'mh111' and you go down to +the next row you'll see a 0 and if you go one row down another 0. This is the +buffer size, 100, for `u`. The column to the left is the same for the `t` +variable. + +Thus it seems that in order to get the generated output correct one needs to +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). + # 1995