Format and typo fixes. Starting with this year I actually did more
thorough typo fixes. It might be that I did some of this in earlier
years too but I am sure I did it for this year and beyond (at least up
through 1995 .. not sure about years beyond that that I have also
edited). Even so I'll probably want to do another pass through all files
before I can say that the typo issue is resolved. That includes possibly
other files and the worst of all files in my entries.
As noted in commit 3958bbdb04:
Updated URL for author as it has changed. It's very little on his
page and the only page that suggests it is his is the ioccc.html
page. I couldn't find anything else.
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.
There were many many README.md files with the wrong heading level for
different sections. These have been changed.
To help go through the changes it should be noted I used sgit and also
here is what is changed:
The 'Try', 'To build' and 'To run' lines have two '#'s. Some had one and
others had three.
An exception is that in 1984/anonymous/README.md for the alternative
code that had three '#'s. This is not consistent yet and it might be
that only two are desired. But for now that one at least has three.
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.
With the exception of lmfjyh which relies on a bug in gcc (that was
fixed in gcc 2.3.3) we have got all 1993 entries to compile under linux.
A couple will not compile under macOS and this is because gcc under
macOS is actually clang despite what many might have you believe (see
below) which is more strict about the second and third arguments of
main().
In a couple entries we used patches from Yusuke Endoh. Thank you Yusuke!
In others we (that is I aka Cody / @xexyl) fixed them (myself). There
was a question to be answered about whether to add #include lines to the
files themselves or add -includes to the Makefile. Since there are
pending changes to the Makefiles which will affect the CFLAGS (and
there's no CINCLUDE variable in these Makefiles yet) we opted for
updating the source files themselves.
One more note about the Makefiles: the 1993/Makefile was modified but I
added an XXX note to it to indicate that it should be fixed once the
other Makefiles are fixed. Specifically it now allows from 1993 one
to run `make' and compile the entries. The comment has what it used to
read and should be but for now is not because of a problem in the other
Makefiles.
As far as gcc under macOS as you can see it is not actually gcc but
clang:
$ /usr/bin/gcc -v 2>&1|head -n 1
Apple clang version 14.0.0 (clang-1400.0.29.202)
If you were to use clang -v under linux you might see something like:
$ clang -v 2>&1|head -n 1
clang version 15.0.7 (Fedora 15.0.7-1.fc37)
and with gcc:
$ gcc --version |head -n 1
gcc (GCC) 12.2.1 20221121 (Red Hat 12.2.1-4)
If you do by chance have gcc compiled and installed under macOS these
entries will probably work there.
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