It seems more like a feature than a bug if one enters input that is not
a number > 0. This was considered a bug in the bugs.md file and noted in
the README.md file but it seems like it's not something that should be
fixed but merely noted as a feature.
Per discussion months ago with Landon the idea of rot13 will in general
be discouraged and the website will likely have a link to undo rot13
text. Also this was necessary to figure out how to format the
file.
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.
NOTE: this is just one way to fix the problem described below but it can
be modified - perhaps greatly changed - or rejected and done
differently. That being said it does isolate the entries that can be
modified except for the one by Simon Cooper as I had intended to do all
entries before a commit but I am too tired to continue and there are
more important things to be done for the IOCCC (hopefully later today).
I don't mind but I wanted to save Landon some of the work as I started
the problem even though all with good intention after Landon noted he
wanted to thank those in the README.md files.
First I would like to also apologise to any previous winners if there
was upset or concern; this was all done with the best intentions and I
know that it was a fine line but the judges' goal is to make it so
previous entries do work in modern systems so that everyone can enjoy
them. Still I am sorry if I caused any offence or anything else! I
actually agree with the situation and I had been wondering about how to
go about it too. Now for the rationale behind this update.
A couple previous winners have voiced concern about the way the thank
you notes are displayed in the README.md files I have started the work
to save Landon some of the trouble as although it was with good
intentions (and based on the note that Landon wanted to thank those who
fixed an entry) I started the problem so it seems only right that I help
rectify it. I also agree with the problem and had thought of it before,
even thinking that in some entries it needs not have any reference to
anyone but the winner! This commit has removed the thank you notes from
several entries and added a THANKS.md file.
The THANKS.md file has the rest of the entries that were fixed as well
which should if nothing else help isolate the entries that need to be
modified. Some entries actually referred to me but were not a thank you
note due to a fix; some were from winners themselves for instance.
Note that I did not update the bugs.md file or any other file that might
refer to these things in the README.md files. The bugs.md for instance
refers to adding credits to those who fix problems or provide missing
links or files to the respective README.md files and this will have to
change once the way this is done is finalised. But hopefully this is a
help to Landon so that he may also focus on the important jprint tool in
the mkiocccentry repo.
If one passes to the Fibonacci or theorem_bkp program 0 0 it enters an
infinite loop repeatedly printing 0. I think this is better to be just
documented and not fixed. Another condition where this occurred was
fixed but as I recall that might have affected usability and this one in
any event does not.
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.
I did this a while back but somehow forgot to do a git add baruch.alt.c
so the alt code was only referenced in the README.md and Makefile. That
has now been corrected.
This is because not all systems have zsh installed. Why not bash?
Because it returned a syntax error. It might be possible to get it to
work with bash but there's a chance that a system might not have bash.
Of course SHELL is set to bash so that might be an irrelevant point. I
know not all sh implementations are good so that's another thing to
consider but for now it'll do.
Add to README.md that one thing (a crash without an arg) is at this time
not a bug but a feature.
Fix the statement that a negative number causes the entry to enter an
infinite loop. Instead any input that's not a number > 0 will cause the
program to enter an infinite loop.
Due to a misunderstanding between Landon and me after some discussion on
GitHub it was recommended that I reapply this fix so I have done so.
I've updated the bugs.md file to change the definition of INABIAF (it's
not a bug it's a feature) as well as adding another known bug with this
entry to the file (this has also been added to README.md).
In bugs.md I also added towards the top a note to the winning authors
about fixes applied to their entries. Particularly if an author objects
to the fix we'll be happy to undo it even if it impacts the usability of
the program. There there is an apology too. We know there's a fine line
and although we have tried to use good judgement invariably some will be
the wrong decision. Thank you for understanding and apologies!
Removed this task from todo.md, changing it to refer to just make sure
all README.md files have been checked for typos.
I _believe_ this means 1990 has been checked for typos except for the
1990/README.md file itself.
Fix formatting in README.md.
Removed statement of judges that they fixed it for modern compilers that
object to 's' added to an int for short int as this is what I did and
the source that was imported had not been fixed though this might have
been a simple mistake. I had not noticed this before.
Update bugs.md: a known bug and one INABIAF (crashes on no arg).
Added alt code with the 1s as it's instructive to show what was once
allowed but is not now.
Originally I had thought that a command in the commands to try did not
work in macOS. But I looked at the code a while back and it's only
because of the errno == 0 message in macOS and the fact the entry uses
perror(). I noted it's not a bug in bugs.md at the time but I did not
remove that part from the README.md (the part that says it doesn't
work).
The typo of most importance (maybe the only typo) was that when I linked
to the archive tarball I left off /archive in the link.
Noted in the judges' comments that in the smaller version provided by
the author the exit() returns void problem is fixed but it still uses
gets(), not fgets(). I don't see the reason to do that as it'll compile
and it's really only an aside and not the entry.
This includes moving from the author's comments the note from the judges
that he had sent a note to the judges asking something about the award
title along with the judges' reply. It seemed like the more appropriate
place to have it.
Format fixes.
Remove judges' rot13 spoilers (or rather decipher it) since Landon told
me gone are the days of spoilers. He also told me that the eventual
website will have a button to click to decipher the rot13 spoilers but
I'm keeping rot13 content from authors at least for now.
Format fixes in README.md including making unordered lists to make the
rendered content easier to read and follow.
I've also become aware of a problem with the way the author formatting
was done in recent days in the README.md files that now have to all be
fixed: there needs to be spaces after each line or else the author
information will be one line which is definitely wrong. I think the only
one I got this right is, ironically or not :-), my own entries, namely
because I wanted to make sure that they looked okay (I did 'make sure'
that some of the others did too but that was to changes that I was
unsure of .. ironically leaving out one I should have known but probably
just forgot). Thus many pull requests will be made unless I do it in a
mass fix which I suppose is possible to save time.
As discussed on GitHub this is rarely needed for gets() to fgets()
change (which again is useful - but problematic either way - to prevent
warnings during compile, linking or execution of the program sometimes,
including with this entry, output interspersed with the program's
output).
There was no need to modify the Makefile as the alt target was already
not defined.
BTW: if the compiler compiles, the linker links and the user executes
does that make the compiler the jury, the linker the judge and user the
executioner? :-)
Fixed formatting in README.md.
Add alt code based on authors' suggestion except that the string
replacement was not done because it seems like the output would be not
better but worse. There's a joke in the alternate code section of the
README.md file.
In this case these were not features.
The most important bug fix actually prevented the entry from working
properly: the generated code for the Fibonacci sequence just printed 0
over and over again. Added a segfault prevention here as it seemed like
if I'm going to fix it I might as well fix it properly. Removed this bug
from bugs.md.
A set of possible issues with the char m[][] array was also including
the size limit in the fgets() calls (that was my fault due to missing
the proper type of m at the time). Still might be good to test with
longer lines of input. Commands with known output are correct
nonetheless.
The other bug was due to the gets() to fgets() change where blank lines
were added where they shouldn't be. Now one can do ls | ./sorter and get
no blank lines after each file in the listing.
The alt code was the version that works for modern systems before the
gets()/fgets() change (the fix being changing a read only char * to a
char []) but this is not at this time in the archive. The README.md file
refers to the archive, noting it is the original code before the bug
fix.
About why it's useful. It's a problem to keep gets() but it might be a
problem to not keep it as well. Nevertheless with macOS the output of
the alternative code (which probably should be deleted but this can
happen another time) is confusing:
$ ./tbr.alt
$ warning: this program uses gets(), which is unsafe.
[]
The [] is the cursor on a blank line. The first line of output of the
program (which is not supposed to have a newline) instead has the
warning and then a newline appended to it.
About why it's useful. It's both a problem to keep gets() but it's also
potentially a problem to change it to fgets(). But as it will prevent
alarming the user with warnings about gets() and also causing messed up
output (see below) this is useful.
With the original code one will see under macOS something like:
$ ./cmills.alt
Shuffle...
warning: this program uses gets(), which is unsafe.
Total $1000. Wager?
which is very wrong.
I did not delete the cmills.alt.c but perhaps it should be deleted. That
can come another time.
As part of the redefinition of INABIAF one of the segfault fixes has
been undone. The others were necessary as part of making the entry work
in modern systems but this one should not have been done. Instead the
Makefile and README.md warn about it.
I did however discover another bug with this entry that makes one of the
generated programs not work. I documented that in bugs.md and I'll look
at it another time.
As part of the redefinition of INABIAF the NULL file protection was
removed. The bus error fix, the erroneous prototype to fopen() and the
fgets() fix are still applied as these allow the entry to work properly
(and without an obnoxious warning at compile, linking or runtime about
gets()).
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.
Landon Curt Noll