This is based on the suggestion of the judges that some people might
want to slow the game down a bit.
It is easy to configure at compile time like:
make CDEFINE=-DZ=18 clobber alt
More details are in the README.md file.
Updated .gitignore and thanks file (not just for this but also
making something else clearer in another entry).
Redefined gets() so that the code can refer to gets() not fgets(). That
change was useful (as noted before) for preventing an annoying warning
being interspersed with the output and warnings at compiler and/or
linking.
This is to make it more standard which further allows one to run make on
some other source code, say because they want to try and fix an entry
but forget to update the Makefile. Or if they're the author they can not
worry about it in some cases. But since LDFLAGS is the standard way it
seems better to have the LIBS variable in the Makefile be LDFLAGS.
Maybe there is a reason to not have this and I'm happy to close this in
that case but it does seem better this way so I'm doing this commit.
As besides the entries that are not supposed to compile/cannot compile
due to architectural limitations all the entries can compile in macOS
(though some do not work - yet(? I have plans to work on more later)) it
was not necessary to not silence the warnings after all as the entries
that don't work will be easy to identify ('they don't work' :-) ) so I
can just do make CSILENCE= all in the directory of those entries which
solves the problem I had originally thought of.
Some of the Makefiles have retained other changes I had to make
yesterday to get the entries to work with clang in linux but most of
them were either not changed or were made better with the rollback of
the commit that originally silenced warnings.
Now work on silencing warnings for linux can be done.
Due to the fact we now have .orig.c files and thus the possibility of
winner.orig or prog.orig being built I have updated all the .gitignore
files so that these files ignored. This was done with the following
shell commands, for reference:
for i in $(find 19* 200* 201[0123] -mindepth 2 -maxdepth 2 -name .gitignore) ; do echo $(dirname "$i"|sed -e 's,[0-9]\{4\}/,,g').orig >> "$i"; done
for i in $(find 201[4-9] 2020 -mindepth 2 -maxdepth 2 -name .gitignore) ; do echo prog.orig >> "$i"; done
and the two commands is because it was only in 2014 that the winning
entries were renamed to prog so prog.orig is the correct glob.
Used the following script to check for warnings
not silenced via ${CSILENCE}:
```sh
find ???? -mindepth 1 -maxdepth 1 -type d | while read dir; do
(cd "$dir"; echo =-=-= "$dir" =-=-= ; csilence -v 1 clobber all ; echo ; csilence -v 1 clobber alt)
done 2>&1 | less
```
The fix thank you's have been moved from `README.md` to
`thanks-for-fixes.md`.
**WARNING**: Some mistakes may have been made in doing this.
We presume later changes by others will correct any issues.
The `CONTRIBUTING.md` was renamed `how-to-enter.md`.
A 3rd line of links was added to top level html such as
`contact.html`, `index.html`, `judges.html`, `winners.html`,
and `years.html`.
Improved blank line use in a number (but not all) `README.md` files.
The is a file excluded from this commit that has had the change because
there are other changes but the file is incomplete. That file will be
committed when the fixes are complete which will happen at a later date.
Why? Because! :-)
Updated .gitignore.
Added the entry to bugs.md.
Slightly modified the note in the Makefile so that the make all rule
refers to make alt.
The README.md file was updated including succinctly giving the gist
(that might or might not be redundant :-) ) of the entry i.e. how it
worked (though the author also stated this).
Even if it successfully compiles (which will only happen with gcc <
2.3.3 I think it was) the file shouldn't stay in the file system once
the entry has been compiled.
Now if the compilation fails (it relies on a bug in gcc version < 2.3.3)
the bogus file is removed. It is not possible to check the gcc version
in the source code because the file is copied from lmfjyh.c in the
Makefile prior to the compilation. Well it's possible to check the gcc
version but it's too late at that point - the file would have already
been made :-)
This prevents the user form having to do quoting of the file (risking
making a mistake) or using -find . -inum ... -delete after obtaining the
inode (ls -li).
When the idea of having the winning entry directory names match the name
of the authors was decided to be a bad idea after all I forgot to update
the 1993 Makefile with Anthony Howe's entry so that it tried to cd to
1993/howe and not 1993/ant. This caused a compilation error and
prevented 1993/ant from being compiled.
Very few entries do not compile now though that does not mean that all
that compile work - yet at least. Some that don't compile never will:
- 1988/spinellis will never compile with clang. I added alt code for
clang.
- 1993/lmfjyh will not compile except for gcc == (or < ?) 2.3.3 as it
relies on a bug in gcc that was fixed in version 2.3.3. This entry
unfortunately creates a bogus file called:
'";main(){puts("Hello World!");}char*C=".c' though at least it's
excluded in .gitignore ('"*'). The fact this file is generated
is still an issue though and perhaps the entry should be made
alt code and the original could be an #error if gcc >= 2.3.3?
- 1994/westley is not supposed to compile as depending on the
compiler flags it plays a game!
- 2001/anonymous/anonymous.ten.c has to be compiled with -m32 and not
all platforms are able to do this (glaring at macOS here).
- Similarly to 2001/anonymous/anonymous.ten.c this too has to be
compiled with -m32 and not all platforms permit code to be compiled as
32-bit.
- 2004/gavin cannot be linked in some architectures / platforms like
macOS. I actually have a fix I came up with the other day that lets it
compile with macOS but it doesn't do anything either (I have one theory
why that is). I might add this to the repo just so it can at least
compile (via make alt). Even so this entry has some problems for modern
systems including architecture.
- One file in 2015/yang does not compile but I believe this to be the
Makefile. I'll fix this in a near future commit if that is indeed the
case.
All other entries compile (many did not but I fixed many - including
removing the need for -traditional-cpp; Landon also fixed a few and so
did Yusuke Endoh)! Not all of those work however (in all platforms or at
all). I have not tested all either. I am still in the process of this
but these are of lower priority for the moment (though I might address
some before the higher priority tasks if I don't feel up to said tasks
but do feel up to these). This means we've made tremendous progress in
issue #1!
I got the entry to compile quite a while back (Yusuke Endoh fixed the X
code) but I never removed the comment saying that the entry might have
problems with modern compilers.
This to make the country code consistent with mkiocccentry (and I guess
international standard country codes).
This affects many README.md files and (for one line) winners.csv.
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.
Formatting fixes.
Give more of a warning against this entry with gcc < 2.3.3 about it not
working and creating a bogus file, referring to the author's comments as
to the file name.
This includes removing a statement that this could not compile under
macOS. I'm not sure what happened but I suspect it was the wrong data
file perhaps one of the files left by the script. Either way it does
work with macOS.
Fixed formatting as well.
Now it just does nothing if two args are not given to the program. It
seems better to me that it shouldn't crash because of invalid input
unless that's a feature. This is why I've been doing this for other
entries as well. It would be problematic to the program to add a usage
string but I can at least make a check first. Another thought I had was
adding to the Makefile a warning for entries like this but perhaps both
would be the best way to go about it so that users would know that they
had to give certain input for it to work. I don't known but this is a
start anyway.
I also fixed the formatting of the README.md file.
Cody Boone Ferguson