The fact fgets() makes it print another line is less of a problem in
macOS as it already printed two lines - one as a warning about gets()
and then the output of the program. Keeping gets() is a problem but not
keeping it can also be considered a problem. Given it prevents a warning
it's a good thing as it can be potentially alarming.
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.
I noted this subtlety in the log yesterday but it seems that it should
be noted in the README.md too. As I noted: if a line is greater than 231
in length if the program chooses that line it might print the first 231
characters or it might print (up to) the next 231 characters and so on.
Remove warning from Makefile that this entry uses gets() as this is no
longer true.
Update README.md pointing out that this will print a newline after the
output.
I had already fixed this entry to compile with modern compilers but a
problem existed where lines longer than 231 characters (which generally
would not happen but is not impossible) would overflow the buffer. Now
it uses fgets() so this does not happen. A couple notes about this
though.
It right now does print a newline after the output unless the line
length is in fact 231 characters. This seems like a worthy compromise
though. In time I hope to address this so that it does not ever print a
newline (a blank line notwithstanding which does happen and is part of
the entry).
The second thing to be aware of is just a subtlety with the entry: what
happens with a line of length 394? What you'll find is that it might
print the first 231 characters or it might print the last 163 characters
plus the newline (the 231 one does not have a newline).
I've added to bugs.md the part where it will print a newline if the line
length < 231.
At the same time I fixed a path in the bugs.md file that I noticed.
Simply the Makefile header.
Refer to the //www.ioccc.org/bugs.md URL (that will eventually exist).
Now using CC BY-SA 4.0 License to how you may share and adapt the
Makefile.
There is one exception:
$ find . -name '*.hint' -execdir git mv '{}' README.md \;
git statufatal: destination exists, source=1992/albert/albert.hint, destination=1992/albert/README.md
Looking at the two files they differ quite a bit so I've not changed it.
I'll bring this up on GitHub.
We we move 1988-2004 entries from all of a year's winning entries
in a single directory to each winner being in their own sub-directory
under the given year directory.
Cody Boone Ferguson