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.
The problem was that the read only char*z[] was being written to. This
caused a crash which prevented the delightful program from working. The
fix was to change it to 'char z[][100]'. But why not a smaller number
when the longest string is < 100? Because a smaller number caused
strange output and it was easier to do than find the right value: 100 is
that big and it works well so why bother finding the smallest value? No
other reason behind it.
Fixed the shell script too so that it actually works okay (related to
'.' not being in the path in modern systems).
Updated README.md: moved the ttt.sh related things to new try section
and gave an example run (a losing example, challenging users to cause a
draw or better yet win as well as asking them to test something about
the game).
Added a fun parody to the README.md too. Check it out!
Removed this entry from bugs.md.
After discussing it with Landon it was recommended that these fixes be
reapplied.
Updated bugs.md wrt this.
README.md has had formatting fixes as well.
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.
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!
When I started the program I noticed that it ends very quickly. Yusuke
Endoh provided a patch that calls usleep(). I felt that this was too
slow so I added a macro at the Makefile, Z, default 15000, so one can
reconfigure it. Thank you Yusuke!
I also noticed that when starting the game it moves towards the right
and then exits. Yusuke pointed out that if you click the mouse it moves
back towards the centre. I added this to the bugs.md file. Thank you
Yusuke!
Fixed formatting of README.md file.
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.
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.
When fixing the entries that did not work I went a bit too far and fixed
other problems as well. This should not have been done and there was
ever a doubt in my mind about it. The coming commits will be undoing
these changes (though the vast majority that were modified were not in
this category). An INABIAF now includes segfaults both that are
documented and not documented unless it prevents the entry from working.
It also includes other things that are both documented and not
documented.
After all it's not like the winning entries are meant to be code that is
maintainable or good quality (even if they work well). One might even
say that they should be buggy! :-) (and in some cases which were never
touched they're supposed to crash or do this or that).
In the case of gets() versus fgets() this is not so clear. The reason is
that in modern systems one will get a warning at compile time or linking
time (I mostly noted linking time) but also (in some systems like macOS)
runtime. These warnings can be alarming and interfering. In some entries
it caused confusing output a great example being 1990/tbr. The alt code
(which might want to be removed) will show something like:
$ ./tbr.alt
$ warning: this program uses gets(), which is unsafe.
#
The '#' is a blank line but if you notice above it the first line of
output of the program has the warning attached to it. This is both
confusing and annoying. There are other entries with this same problem,
some of them fixed and some not.
If an entry did not work and I fixed that part but also fixed other
issues I've done my best to make sure that only the fixes that are
needed are there.
I also tried to put notes in both the Makefile and README.md of each
entry where there is a problem so as to alert users that this or that
entry does crash if not given valid input so they don't think it's
broken. I might have missed some but as I go through the upcoming
commits I will look at them again to see if I covered them all.
But this commit and the next commits will make the quality of the
winning entries better (if making them more buggy can be called better
quality :-) ) or at least more correct.
Should one wish to see fixes they can use git to find them. In the
bugs.md file I have reworded (and added the exception of the author) the
INABIAF status and moved it to the bottom of the statuses list. I also
probably reworded some of the other statuses and possibly added a status
as well.
The entries that have been added to the file will be committed one at a
time. Some other entries that needn't be in the bugs.md will also be
updated (README.md files for instance) but all of these are ones that
were updated already in some form or another.
For some good old C-fashioned fun I recommend people to compare
sicherman.c to sicherman.alt.c!
To the best of my knowledge with this there are no more entries that
require -traditional-cpp! The configure scripts in 2004/hibachi and
2005/mynx don't seem to be required to compile the code.
It's possible that other entries do need it that I've not yet discovered
but as of now no known entries need it.
Removed entry from bugs.md.
There were a couple problems to resolve. First
#define a(x)get/***/x/***/id())
p Z=chroot("/");L(!a(u)execv((q(v="/ipu6ljov"),v),C);Z-=kill(l);
...
case_2:L(!--V){O/*/*/c*c+c);wait(A+c*c-c);L(!Z)f(A,"\n",c);return(A*getgid());};C++;
does not work to create getuid() and getgid(). The second is that
for/*/(;;);/*/k()){O/*/*/c);
cannot form 'fork())' in modern C compilers. What is quite fun is that
the cpp can!
Removed this entry from bugs.md.
This was also a lot of fun to fix. It took a fair bit of tinkering but
it was a lot of fun to figure out and now it works like it does with
-traditional-cpp!
Removed this entry from the bugs.md file as it now works.
Also added to the bugs.md a minor clarification about another entry
that is in status INABIAF (about warnings).
This one was also fun. By chance I noticed the '{' next to the read()
function. Easy enough to miss when very tired. Anyway I had to prototype
that function as 'int read(int, void *, int)' and then in that function,
in the call to write(2), cast 'i' (which is the void *) to int. This
fixes the problem and now it works with macOS and linux.
Removed this entry from bugs.md.
This was fun to fix. What prompted me to do so is that I noticed that
the patch from Yusuke Endoh actually doesn't work in fedora linux. It never
worked with clang as it required -traditional-cpp and also had
non-standard second and third args type to main (not a char ** but
implicit int). No more. This entry now works with both linux and macOS!
I was able to remove all the macros as they were problematic and not
needed. The code that used them was updated to be what was necessary.
Add to Makefile inclusion of stdio.h and math.h (printf, floor).
Some systems require -lm so that was also added to the Makefile.
Very little else was required to make it work.
The decot.alt.c is the version patched by Yusuke but fixed by me to
compile with fedora's gcc.
Removed this entry from bugs.md.
I by accident had left an incomplete sentence in the file (probably
jumping to another entry when updating the file with multiple entries
and then forgetting to go back .. numerous times). Fixed that and added
a bit of information (or at least elaborated a bit?).
Fixed scripts to use LC_ALL=C. This was necessary especially for de.sh
as the tr invocation had invalid bytes. Similar requirement was in
getwords.sh. But since I changed the one I decided to change the others
too.
I note that both before and after the fix the alternative languages do
not work under macOS or fedora linux. I don't know if this is the wrong
locale (the author does suggest UTF-8) or the dictionary or something
else but I noted it anyway.
I added this latter problem to bugs.md. Whilst at it I added some notes
and fixes to bugs.md.
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.
It should have said subsection not section when referring to the
requirements of EOF not being that it's -1 but that it's some negative
integer value.
Also made worse not wore.
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.
Since the entry cannot yet compile if it's changed to use fgets() I
decided to take a look at the source. Quite quickly I noticed something
fun at the top. If you look at each column and go down row by row you
see it spelling out the code! I wrote the following tips in the bugs.md
as an example:
Take a look at the interesting comment as well as the `int
r=0,x,y=0` at the top of the file. If you look at each column go
down that column you can see how it spells out the code. For
instance the first column looks like:
i
n
c
l
u
d
e
<
s
t
d
i
o
.
h
>
If you join the lines you end up with:
#include <stdio.h>
If you look at column 25 which is the end of the word 'mh111' and
you go down to the next row you'll see a 0 and if you go one row
down another 0. This is the buffer size, 100, for `u`. The column to
the left is the same for the `t` variable.
Thus it seems that in order to get the generated output correct one
needs to provide the correct input in comments or possibly by
rearranging some of the code (this was required to make the
generated code compile at all when changing the buffer size).
From this it should be possible, theoretically, to come up with the
right code so that everything works okay.
The problem was the exit() (redefined) was not being called in main().
This used to work but no longer does.
This fix was based on the file on the IOCCC website isaak.ansi.c. One of
the fixes in that one was the fact that in the older days one could
define define to something else and use that new macro as a define. But
since this was already done I didn't see the point in doing it again (it
was already in the repo as the diff shows - isaak.alt.c is the
original).
Removed this entry from bugs.md.
Formatting fixes in README.md.
Add entry to bugs.md as it will abort due to assertion failure. But this
is expected and the entry works fine (open the html file and you'll see
that). So INABIAF.
Moved the important notes about all changes above the list of statuses.
This seems like a better place to have them.
Add new status missing file(s). The one entry with this I plan to take
care of later on when things are more consistent.
Now anyone can enjoy 1984/mullender! This was a slight change to code
originally suggested in the faq (which was also updated, see below) made
for modern systems (since CPUs are much faster nowadays the duration for
usleep was much too long so one could not really enjoy the entry).
Updated bugs.md to remove this entry from the bugs.md file.
Also updated faq.md with another item. Unfortunately I had already added
another entry to faq.md and had failed to commit it before doing this
change (and adding it to the faq): how to get X11 entries (or actually
any X11 application) to work in macOS Mountain Lion and beyond. This is
why that faq entry is on this branch. It was not intended but it felt
like this change should be on its own branch / in a separate pull
request. I did not want to temporarily modify faq.md simply for this. I
have more changes to faq.md to make but that'll be on another branch so
that I have these changes there as well.
The program would also crash if the arg had any character that's not a
digit or if the arg had only 0s in it (it would work if it had 0
followed by a digit other than 0). In other words if it is converted to
0 it would segfault.
The bugs.md file has been updated as well to note what's also now in the
README.md file: even a relatively small number can cause a substantial
amount of lines of output. For instance the number 9 causes 771999 lines
(!!) of output.
I used a patch from Yusuke Endoh to get it to work with gcc. Due to the
different messages with different compilers it's expected that this
won't work with every compiler.
I provided a 'runme.sh' script to run the command in the correct way.
I made the entry use fgets() not gets().
I updated bugs.md pointing out that it does not work with clang and
alternative code is welcome.
The question of whether this is worth calling a bug (or a bug that
should be fixed) or not is certainly one to consider and I put that in
there. Nevertheless with non-binary digits the program will crash.
Should this be fixed? I don't know. I'll certainly look at it in time
though.
The problem was that the int * needed to be a long *. It became apparent
to me when evaluating it with lldb as I noticed a pointer was long, not
an int. This does not cause a problem with linux. I have no 32-bit
system to test but I don't believe this will be an actual problem.
New sections and statuses.
Added some entries. I am going through all entries to find more to add
but I ended up fixing an entry which I wish to commit so the next
updates to this file will be on a different branch and most likely later
on today.
In general the compiler warnings should be ignored. Only if the entry
does not work and even then only sometimes should they be fixed.
Sometimes fixing them will introduce bugs and/or crashes. Sometimes a
fix which works correctly (see my fixes to 1986/holloway and
1998/schnitzi for two examples) will introduce new warnings which MUST
NOT be fixed. Thus a general section warning against fixing warnings
lest they cause other bugs which might or might not cause other warnings
to fix (if even possible) to make it work without warnings is something
that should be there. I also noted how although some entries in the list
do have warnings noted we will not try and keep them up to date as
different compilers and almost certainly platforms (e.g. data type
sizes) generate different warnings. Sometimes this does mean that an
entry will only work on certain platforms and some might or might not be
fixable but most likely they cannot be fixed easily and even if they can
be it almost certainly will be just as non-portable (importable ? :-) ).
I did update the list of warnings in one of the entries I fixed however.
Increased header (text size) of status lines..
Make 'Status' 'STATUS'.
Added an entry (1989/paul). I am actually aware of more entries that I'm
working on (and I'm working on this one too) that do not work and/or
crash but I've not yet put in the file as I sillily (which amusingly
macOS vim dictionary does not even recognise as a word but it absolutely
is and OED will confirm it!) did not note earlier (which means I have to
go through all entries for the third or fourth time .. if not more times
for some!).
Added some statuses. Some entries can have more than one status now: the
idea is sometimes they have more than one problem OR the different
statuses are related in the entry.
Added some bold and italic in some places to make things stand out
better. The same with making some words all caps.
Add years without an IOCCC to make it easier to recognise that the year
isn't missing but because there simply was no contest that year.
Possibly other things.
Additionally I have had the thought of making a table of contents for
each status (in the list of statuses) so one can jump to the entry
they're interested in and so one can see the different entries at a
glance. There would be a problem, maybe, with entries that have more
than one status but that could be easily addressed by having it in both
statuses (having a note under one would mean we would have to
arbitrarily select which list to add to and also would make it harder to
find though maybe only slightly).
This still crashes and may very well not work even if it doesn't but I
cannot determine that. I just fixed the initial segfault when opening
the file. I believe it will take much debugging, a 32-bit system to test
it on and also a knowledge of the ELF format. There might be other
things but I believe those are the minimum requirements.
I did fix the supplementary program bellard.otccex.c so it does not
segfault and seemingly it works too (I didn't really evaluate that the
output is correct but it does process the args anyway).
I updated bugs.md to note that this entry does not work and any help
would be appreciated.
I removed from bugs.md the suggestion that it does not work for macOS as
I fixed that. I also slightly reworded the entry in bugs.md (about
warnings to ignore).
Add to README.md summary of problem.
It segfaulted due to wrong type of a variable.
It still crashes under macOS which I will be looking at in the near
future but it at least works for linux.
I noted in the bugs.md a compiler warning that should not be changed as
it's not a bug and in fact 'fixing' it will introduce a bug.
A line for one entry was in the wrong entry.
I added that I'm working on them (with some humour injected there) but
others may try too .. if they are okay making people very sad :-)
Added more information / examples in some of the status sections and
possibly some of the entries that are listed.
Improved bugs.md by sorting entries by contest year
and using a one-line status string.
This will make it much easier for someone to find
and entry in the list.
A summary of statuses is found at the end of the file.
Though this will not work as is I have changed the code to scan for
https as well (it exited before). This is so if someone comes up with a
clever command line to make it work it can. A secure connection has to
be established before http commands can be given but now it at least can
connect (though it's been a while since I've played with sockets so
maybe I'm forgetting some detail - one does have to specify the port but
I gave an example in the README.md file for that).
In the README.md I pointed out that one has to specify http:// (or else
https though with the caveat noted above). I also explained how to
specify an alternative port.
I also noted the https issue in the bugs.md file in the INABIAF section
('it's not a bug it's a feature').
As well I changed the try command in the entry README.md file to refer
to a page that does not use https as trying it on the ioccc website
(what it used to) will just return a 301 error.
The segfault in 1996/westley I fixed some days ago so there's no need
for it to be in bugs.md.
Added the requirement for 32-bit arch and no optimiser in 2005/giljade
but suggesting it might be possible to fix it for 64-bit systems.
Probably this should be in a different section but I put it in the known
bugs to fix (even though it's not necessarily a bug).
Typo fix in 1990/jaw.
To see 1984/mullender in action we don't need an emulator: one can use
2015/endoh3 instead. I noted this, linking to it, but also noted that
otherwise one would need an emulator for the entry.
2004/gavin actually works. The problem is it doesn't work under macOS
at least with the M1+ chip (might or might not work with Intel). I still
kept the recent changes to the file but I noted it's not related to the
problem; it's an architecture issue.
This unfortunately does not include making this work in modern systems.
I have used the cpp and I have had some ideas but I don't have a system
where I can test any fixes so it's probably not going to be done by me.
Nevertheless I have fixed the formatting of README.md, noted that it
doesn't seem to work (Yusuke Endoh came to the same conclusion) and also
fixed a typo in anonymous.ten.c (which 'sings' the wonderful English
counting song Ten Green Bottles .. or at least the theory is it's
English).
This entry has been added to the bugs.md file and I have provided a
number of hints that might (or then again might not) help for anyone who
is brave enough to try fixing it.
As far as the change to anonymous.c itself: I simply added some #includes
for functions that are used.
main() had one arg, a char *, and this is against clang requirements.
There was no inclusion of setjmp.h and so the longjmp() function
implicitly returned int and was allowed to take the wrong number of
args. It should return void however and this caused a problem with
binary expressions. The comma operator has been used for this but it
might be a problem in that by having ,1 after each it will make
expressions that could turn out to be false to be incorrect.
The longjmp() was being called with one arg which was an element of an
int[4][1000]. This is obviously incorrect but at some point it worked.
Without the prototype this is not a problem but both before (gcc) and
after the compiler fix (with gcc and clang) it did not work with linux
(in this case fedora) or macOS. The code as it now stands has the same
problem as it did before the compilation fix: it lets you input a bet
but then it does not accept any input after that; it prints nothing more
but it should print a new hand. This issue has been put in bugs.md.
My guess (in my tired head) is it has to do with the abuse of the
longjmp() and/or the comma operator making the expressions always 1 (at
least that side of the expression, thus if it gets to the longjmp() part
it will always be 1). Perhaps it should be ,0? I don't know but I might
try that next (I would guess it should be whatever an implicit int would
return without a return statement but that's just a guess). But given
that it stops working at the same spot perhaps it's not the comma
operator. Maybe the function needs to be broken up into several but I
don't know and that might or might not be worth the effort.
Finally it returned main() itself but now it returns poke() which has
the body of what main used to be.
See bugs.md for more details.
The example commands in the judges' comments had some problems that gave
an error message when running them.
I have also figured out the apparent problem with macOS in the command
under the try section being:
echo "Quartz glyph jocks vend, fix, BMW." | compress | ./btoa | ./jaw
But it's not actually a problem. It uses perror() and under macOS with
errno == 0 it shows:
Undefined error: 0
whereas linux shows 'Success'. So it's not actually a problem with the
entry at all. In fact the condition that triggers that call is the same
in both linux and macOS.
I've updated bugs.md to note this and I also updated the README.md to
note it (and to refer to the bugs.md file for more details).
The thank you to me is because I missed it earlier on when I fixed the
scripts, simple though the fixes were.
Cody Boone Ferguson