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.
It objected to the incompatible pointer type passed to time(2) as what
was passed to time(2) was an int, not a time_t *. One way would be to
disable the warning but I chose to cast the parameter to a time_t * to
get rid of the warning wanting to be triggered at all.
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.
Unfortunately the link is dead so we have to use the Internet Wayback
Machine until such a time that a new link is found. Perhaps this should
be added to the bugs.md with the status about dead links but this has
not been done for the websites which were archived. This can be
determined another time - or not.
At the request of Landon all Makefiles have had trailing spaces removed.
The request also included README.md files but this is more complicated
as some lines have to end in spaces in order to force line breaks. For
Makefiles it's fine though. Tested the Makefiles by doing 'make clobber
all everything' from the root directory and all appears to be fine. This
testing is important because depending on how this process (removal of
trailing spaces) was done it could break the Makefiles; for instance
trying something like:
sgit -e 's/\s.*$//g' '*Makefile'
would rather break the Makefiles. This makes sense to anyone who knows
my script (and obviously sed :-) ) as long as they're not also tired but
I AM tired and so it was the first thing I tried (without thinking of
course ... though I had first thought of the correct way :-) ).
But what happens to the universes (yes I at least want to believe in the
multiverse theory and I hope it's true :-) ) when trailing spaces are
removed? :-)
As it turns out the only Makefiles touched were:
modified: 1987/wall/Makefile
modified: 1992/adrian/Makefile
modified: 1994/ldb/Makefile
modified: 2000/anderson/Makefile
modified: 2001/anonymous/Makefile
modified: 2001/bellard/Makefile
modified: 2004/kopczynski/Makefile
modified: 2015/howe/spoiler/Makefile
modified: 2019/karns/Makefile
and most of them were my fault.
Mary Ann Horton (who gave us uuencode, contributed to BSD Unix amongst
other things) is transgender and she goes by the name Mary Ann so the
website should also say that (it had (Mark) in it which was her
birth name).
Fixed the URL as well as the old one is no longer valid.
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.
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.
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 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.
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.
The problem is that the getc() functions return EOF on error/EOF but it
assumed that it returns -1. EOF is not required to be -1 but merely an
int < 0 so on systems where it was not -1 it could be a problem. But
changing the != -1 check to be != EOF caused a new compiler warning and
errors. However since EOF < 0 and since the code functions fine with the
check being >= 0 the code now checks that the return value of getc() >= 0
as the condition of the for loop. This takes care of any problem where
EOF != -1.
Fixed accidental change in shapiro.md code excerpt. Note that that one
(the first one) does not actually work but it never did (or if it did it
doesn't in modern systems). I'm not sure this is a problem though as the
author stated that without the comments the program will not do anything
right. I believe the author was showing the algorithm without comments.
Format fixes in README.md.
Added note from author about terminal configuration from Brian at the
top of the README.md and the Makefile so that it's easier to see.
Using the spoiler section from Brian I converted it to compiler commands
(in the README.md) and made a spoiler.sh script to run them - to make it
easier to see the game in full for those who just want to see it and not
try it.
Added try section so one can see how it really does output itself. Well
'output' and 'itself' might be better wording. :-)
Fixed formatting in README.md.
Added to .gitignore the file that is created in the new try section.
Rename shapiro.info shapiro.md and make markdown format.
Format fixes in README.md.
Add try section in README.md.
Add this entry to bugs.md for some systems. Specifically the entry
assumes that EOF is -1 but this is not required by the standard; all
that is required is that it is some negative number (see 7.21
Input/output<stdio.h> subsection 1 in the standard).
That's fine and well but changing the code to check for EOF breaks it
terribly. I have added to bugs.md the problems and some tips in solving
it (assuming it's at all feasible which is not entirely certain at this
point and perhaps is not even worth it).
Formatting fixes in README.md. Also refer to bugs.md file where I give
hints on the magic of the entry in order that it can hopefully be made
to use fgets() and have an increased buffer size.
Updated bugs.md about this entry with an important point about the
fgets() / buffer size issue: it can very easily be made to use fgets()
and having an increased buffer size. But the program is supposed to be
able to be fed its own source code and generate output that can do the
same thing and is compilable. Changing the code to use fgets() will
cause compiler errors in the generated output. As well even though I
changed the buffer size it is not generated in the output when feeding
the program its own source code.
In the bugs.md file I also pointed out just how sensitive this program
is (by design): a single space in the wrong place or a single character
in the wrong place can break the program; it's very sensitive.
One should be able to do:
./schnitzi < schnitzi.c
and compile the generated output. That new program should be able to do
the same thing as well.
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.
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.
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.
An example file that would cause the entry to crash is the Makefile. Now
it won't crash. Strangely without increasing the buffer size but even
using fgets() the Makefile did crash the entry. Changing the buffer size
is not a problem but whether or not some other larger file will cause a
problem or not I do not know. I don't see how it would but I don't see
how this happened either.
Cody Boone Ferguson