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).
As part of redefining INABIAF the entry now has an equivalent
functionality with the generated output. The bugs.md file still has
hints on how to get this to use fgets() (for why this is helpful see
that file). As a starting point I have the original buffer size increase
in schnitzi.alt.c as it would be useful to see how it works and to maybe
get the entry to use fgets(). Unfortunately keeping it using gets() is a
potential problem but changing it to fgets() is also a potential problem
(this goes for all of the entries that use or used gets()). This entry
however still uses gets(). The change is the smaller buffer size which
means that the entry can not handle big files.
The Makefile and README.md now refer to the small buffer size.
As both Landon and I have been wondering if changing entries to use
fgets() is bordering on tampering with entries I decided to make the
original (sometimes bug fixed) versions (using gets()) alt code. I had
originally started to make the fgets() version of each entry the alt but
since the fgets() versions can handle input better and since some also
fixed bugs (see below) I decided to make the original version the alt
code (this also is how it is for other entries).
There were some exceptions here. If the change also fixed some crashes
or other bugs outside of the gets() to fgets() conversion I did not
bother to make an alt version. An example is 1992/dds. In some cases the
alt code does have bug fixes in which case they were added.
Updated the Makefiles and .gitignore files as well for the alt target
and the new files (compiled and in the case of 1992/adrian additional
source files in the Makefile alt rule).
This should solve the problem observed by Landon and me. It wouldn't be
a problem to change it so the alt version is the one that uses fgets()
but I think that might be the wrong choice.
In some entries I altogether avoided changing to fgets() say if the
author notes it uses gets() (in one case even providing a version that
uses fgets()). In some cases using fgets() introduces a bug so those are
also not changed.
As for 1990/tbr there's a strong reason for not having the fgets()
version being the alt. In macOS in particular (in linux - or maybe gcc,
not sure - it shows a warning at linker time) it will mess up the first
line of output in a potentially confusing way. For instance:
$ ./tbr.alt
$ warning: this program uses gets(), which is unsafe.
# nothing here, what to do?
And that touches on another issue of making the alt version the one that
uses gets(): the warnings that can be alarming during compilation,
linking and (in the case of macOS) runtime.
Not all entries should be or can be changed to fgets() but some can and
it's warranted for these reasons. More will possibly happen in the
future.
Cody Boone Ferguson