The way the Makefile was constructed meant that the program just
decompressed the real program which is only the first part of the
program. As the judges noted it could be said to break rule 2 (in a
way?) because the code actually is a decompressor of the real code. So
in order to get the entry to do what it's supposed to do the Makefile
rule was modified to be:
${PROG}: ${PROG}.c
${CC} ${CFLAGS} $< -o $@ ${LDFLAGS}
./${PROG} | ${CC} ${CFLAGS} -x c - -o $@ ${LDFLAGS}
which first compiles the program to hou and then runs hou, piping the
output to the compiler to compile it into hou again. This way when one
runs hou (after running make) the actual program is run, saving
viewers/users from the extra step (and potential confusion). The
README.md file also shows how to just generate the decompressed source
code and notes the author's remarks about a.c.gz and a.c (what was
included in what was a.c.gz) so as to clarify that the file is not
missing but rather that it's not included and does not need to be
included either.
Since the real code uses math.h the LDFLAGS were modified to include -lm.
The .gitignore file was updated to have the PPM files that are generated
by the program.
Added an INAFIAB section to the README.md and the bugs.md file: it does
not terminate on its own and since the author mentioned it wrt a rule it
felt like it should be put in such a section.
Format fixed README.md.
With this commit only a final pass should be necessary to say this entry
has been finished though it's entirely possible I discover another
problem I guess.
Added fun.c and make make all compile it: this is what the judges
suggested one try compiling with different compilers and checking the
results. I added how to specify the compiler.
Added slen.sh script, corrected for shellcheck, which runs the command
the author suggested (and which the judges added to their remarks), to
make it simpler for viewers of the entry.
Added INABIAF section to README.md: if no args are specified it will
very likely crash or do something funny. A similar such thing is in
bugs.md as well.
Updated .gitignore.
Format fix README.md.
Added fun.c and make make all compile it: this is what the judges
suggested one try compiling with different compilers and checking the
results. I added how to specify the compiler.
Added slen.sh script, corrected for shellcheck, which runs the command
the author suggested (and which the judges added to their remarks), to
make it simpler for viewers of the entry.
Added INABIAF section to README.md: if no args are specified it will
very likely crash or do something funny. A similar such thing is in
bugs.md as well.
Updated .gitignore.
Format fix README.md.
The alt code _should_ (keyword :-) ) run in Windows. This code is based
on the author's remarks. It is done by (at the compiler line) undefining
KB and defining it in the source code (cable3.alt.c) as the author
suggested.
The cable3.c now #includes unistd.h: this is because the author
suggested in some systems it might be necessary though the example the
author gave no longer exists for current versions (the last 32-bit macOS
to support 32-bit binaries was version 0.14 Mojave and even that was
64-bit and Mojave was released in 2018 with a new version released each
year since then). This does trigger a warning in macOS but we now
silence that warning as well.
The runme script now passes shellcheck (make '[ .. ]' '[[ .. ]]').
Format fixes in README.md including a few links where this seemed like a
good idea (for instance websites).
Updated .gitignore: added cable3.alt.
As as of yesterday there is no need to #undef localtime any more (if
there ever was: the fix I made to let it compile did not in the end need
it but it was the first thing I had done so I kept it in) this has been
removed as well.
The screenshots provided by the author have been linked into the
README.md file so that they should display in the html version.
At least one file was changed in name (in the README.md file) to what I
believe is the correct name (it was a non-existent file).
Updated bugs.md to refer to a file that is not found that the author
referred to.
Add bios.asm that author referred to: found at the GitHub repo for the
entry which the README.md now links to (was another website that no
longer exists).
I also removed a -Wno- option from the Makefile as the entry relies on
this warning. This is not strictly necessary as the script that I added,
runme.sh, directly compiles it, but it felt like it shouldn't have it
anyway.
In the bugs.md file I gave some hints as to why this does not work with
clang.
In the thanks file I broke up a paragraph into more than one paragraph.
I have tried to make the README.md file less cluttered wrt the clang
defects and instead just show how to use the entry, referring to the
bugs.md for those who need to know.
Added script compile.sh which generates the files and tries to compile
them. The script sleeps (by default approximately 1 second) in between
commands but this can be changed to another value (including 0). One can
also change the compiler path in case their compiler is clang or in the
case of macOS gcc IS clang. The README.md refers to this and gives
examples.
The bugs.md and the thanks-for-fixes.md files have been updated for
these changes and additions.
For those who do not know of the clang defects it is discussed in the
bugs.md and unfortunately for this entry there might be little that can
be done. I haven't tried to understand the entry deeply and maybe doing
so would give some ideas for fixes (beyond what I already did which lets
the main program compile with clang - or at least versions that allow a
fourth arg to main()) but this seems less important for now.
The reason it is in alt code is because one of the forms of input (see
below) will, although print out correct output, segfault after
outputting the text. That is when one does something like:
echo foo | ./hague.alt
Whether it might be worth making it the entry itself with a note in the
Makefile and README.md and bugs.md (because it does print out correct
output) can be determined later - or not.
This change required several files to be updated besides the new file
hague.alt.c.
What was once thought to be a bug or possible bug is actually a feature.
With a more lucid head I see that in a certain condition (which I noted
in bugs.md) it very clearly is intentional that one should have to hit a
key (it says return as '<RET>' but it uses getchar() via the pointer
'm'). The condition is !(g-a). I do not know the purpose of it but
INABIAF and so should not be changed.
Thus it's not a possible bug or bug but a feature. This is noted also in
the README.md file.
At one point prior to fixing (for clang) 1995/cdua I noticed that
sometimes when running at runtime it would pause and ask you to press
return/enter again to resume. I have not noticed the last several times
(throughout many days) I have run it and that includes numerous runs
each day and so I have changed the status to possible bug, not
definitely a bug.
If I notice it again I will change it back or else look into the problem
but without it happening it's obviously harder to verify that it's a
problem (and since it's not every time it's also impossible to prove,
especially with obfuscated code, that it's fixed).
Added that some versions of clang do not even allow a fourth arg to
main() which my fix for clang also fixed (I did not know it at the
time).
Also added the joke about how the alternative version will very likely
nuke the USA and the main entry will very likely nuke the world if there
are not enough args specified (2) to the thanks-for-fixes.md file,
updated a bit, and updated it in bugs.md and the README.md file too.
And not that we need any help with this or anything :-) but we do
encourage you to test it. This should not be fixed. :-)
And to those like myself who would want to know: yes (obviously :-) ) it
was and is my own joke that felt right for the behaviour it exhibits
without 2 args and what the program actually does with enough args. Try
it and see!
The problem was the function pointer w(), which points to
XCreateWindow(), did not have the parameters and this caused a segfault
in macOS. Because it takes a lot of parameters I split the line up to
multiple lines by having a '\' at the end of lines (the entire code is
in #defined macros and two #includes).
The issue is that when fixing the interspersed output of the annoying
warning in macOS about using gets() an extra newline is printed out.
This is because fgets() stores the newline and gets() does not. But
since the warning kind of ruins the entry and a blank line is better
than the warning it seems like a worthy compromise. That was already
agreed upon but as it's a one liner and it's already quite long it might
be better to just not worry about it as although kind of annoying a
blank line isn't a big deal.
Although it maybe could be fixed and I might look at it in the future (I
would have to look at Xlib API first at the least) the fact that there
is a known workaround means that (based on discussion with Landon) it
can be considered a known issue that need not be fixed necessarily. Thus
it's now considered, at least tentatively, a feature not a bug. As for
what it is: when you start the game everything moves over to the right
of the screen and quickly ends but if you click on the game screen it
goes back to the centre to allow you to play.
After emailing Yusuke he provided me with the missing files which I have
added to the repo. I removed this part from the thanks (I had noted that
there were some files missing) and removed the entry from the bugs.md
file.
Yusuke offered a hint and through this I noticed the main[] in the
README.md (I haven't yet looked at year 2015 in detail). It is what
generates the fun.tar.gz file (which is now in the .gitignore file as
the files within - except for the README.markdown there - are now in the
repo). I put this code in fun.c and added a rule to the Makefile to
build it (and it is built by default with make all). I also added to the
Makefile the rule to build (also by default) bf2pdp11.c. The README.md
notes how to use fun.c but it does not show how to use bf2pdp11 as I'm
not sure of the main use yet (I guess brainfuck to pdp11 which might be
useful with the brainfuck files added but that's all I can guess at this
time).
On another reading of one of the files it occurred to me that he hanging
I observed with clang (after fixing it for gcc) was actually documented
by the judges in the first place. They noted that some compilers compile
the code into an infinite loop and that is indeed what clang does. Thus
because it's documented it's a feature not a bug.
Make the decot.orig.c what was originally submitted prior to the judges
changing a line due to some compilers disliking that line. The alt
version does not have this fix applied. Note that I yanked paste the
line so if there was a typo that's there too though it appears not to
have that problem.
Updated Makefile noting that the purpose of the entry is to print out
rubbish so if one sees nonsense it's expected.
Fix README.md to refer to decot.orig.c instead of decot.alt.c for the
change made by the judges (that is to see it prior to the judges'
change).
On another look I believe it to be a typo of the author that the prompt
should be 'A>'. I believe it should be what it is which is '>'. Still
there appears there might be a problem but because I am not sure of this
I changed it to possible bug. The problem or possible problem is that
the use of DDT.COM seems to not work but this might be not enough
information from the author or it might be a misunderstanding or
something else entirely.
I also downloaded the files that were referred to in the author's
remarks and added them to the repo. The ones from the SOURCE/ directory
are in the entry directory too as those might be required (though the
use might also be the possible or actual bug described above). This was
done to make it easier to use but also as part of one of the issues on
GitHub.
This was fun! There were a few things that had to be done. First the
expression O-b-f-u-s-c-a-t-e-d; had to be removed from the end of the
code. This served no purpose but it caused compilation errors in the
self-test feature and it does not affect the output of the puzzle
either. Besides that when the variables are declared it spells out the
same thing, Obfuscated.
I also had to change main() to be the old style that is
'main(argc,argv)char**argv;{...}' and I also changed the use of 'cc' to
'make' along with 'rm -f' on the compiled output (due to make otherwise
not wanting to update it).
Now this works with clang too!
Updated thanks-for-fixes.md and bugs.md: for thanks file it now works
full stop and for bugs.md I removed the part that says it doesn't work
fully. There still is the feature where if the source file is not in the
current working directory it will crash or do something strange.
BTW: if a directory only has broken links is it still a working
directory ? :-)
This changes in years.html the 2011/zucker/hint.html to
2011/zucker/README.md (at the top of the file - to do with the IOCCC
logo) and also 1998/dorssel/dorssel.hint to 1998/dorssel/dorssel.md in
years.html (which should have been done in
ccbbacb31b but was left out by accident).
As well it fixes 2004/gavin in bugs.md to refer to (in the Makefile rule
that is included) README.md.
There are still files with 'hint' in the name however. I believe these
to be correct.
Added 2023 to the list of years noting that there probably won't be an
IOCCC this year but it is hoped that at least the IOCCCMOCK will be run
but that this is entirely dependent on the completion of this repo and
the mkiocccentry repo.
Added more to final notes.
There were two things that had to change with my previous fix (getting
it to compile), one in code and one in the Makefile.
Instead of doing ',1' after the calls to longjmp() do ',0'. The way it
originally was is in binary expressions but since the function returns
void I made the result be 0 rather than 1 and along with the other
change it works (though maybe it would work with 1 anyway but it seems
not to be necessary and I don't feel like testing it now).
The Makefile change is that it won't work right with the optimiser
enabled so that was disabled.
I removed this entry from bugs.md (which was listed twice by accident -
and some other things were too) and updated it in the
thanks-for-fixes.md file as well.
As I guessed the reason the game did not seem to work right is not
remembering how to play the game.
I added two INABIAF points to the bugs.md file as well the README.md.
At least one entry was missing (1984/anonymous).
Some entries were removed. One such entry was not ever broken but
instead when I had renamed a file (to markdown) I forgot to update the
DATA variable in the Makefile which then broke compilation. This was
seen in the log and mistakenly believed that there was something wrong
with the entry when there wasn't. Other entries removed were not fixes
but notes.
Various README.md files have been updated for this sometimes just
formatting merely because I opened the file because for instance there
is an alternate version (many by me) that is referred to. I'd not be
surprised if more README.md files have to be updated for this much
better system but these will be found in time when I do another pass
(and some years I have not checked at all yet).
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.
It was an error to fix the segfault without enough args in 1992/westley
as it does not in fact affect the usability of the program and that's
the only time a segfault should be fixed except by anyone but the author
themselves.
This commit required also changing the alt code (that I added based on
the author's remarks) as well as the README.md, bugs.md and
thanks-for-fixes.md.
As of moving the many thanks from the individual README.md files to one
file alone (a move I agree with and had thought of before) the bugs.md
had to be updated to not refer to credits in the README.md files but
rather the thanks 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.
Reword a few things in README.md, add more commands to try (with some
questions)
Add INABIAF section. Added same to bugs.md and put note in Makefile
about it too: in linux the program appears to drop dump cores even
though there is no error (at least at command line?).
Of course the globs do not have a = at the end of the line; that's from
an aliased ls that shows different characters at EOL depending on the
file type.
I also explained how to delete these files assuming that glob pattern.
In the README.md this was done in the new INABIAF section which is where
it belonged in the first place.
The entry appears to leave sockets lying about in the current working
directory. Although undesirable this is not a bug it's a feature.
Updated bugs.md and the README.md file as well as the Makefile.
A useful thing I thought of that might be good to look at for other
entries that show notes in the Makefile is that it might be good (and in
this entry I did do it) to have the note _after_ compilation as it will
be more likely seen. In the case of entries that might not compile with
clang (due to some defects in it) it will have to be done with either ||
or else printed before the compilation (for instance in some of these we
have to say that one should use make alt for clang).
This will be added to the todo.md in a future commit.
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.
In other words now the version that can compile with clang is the
giljade.c and the other is giljade.alt.c.
The reason is that the actual award is about a 2D puzzle and this still
works with the clang compilable version. It also lets those who are
forced to use clang compile the code and at least enjoy the puzzle.
The Makefile has been updated to remove the note about clang or rather
reworded so that the user is made aware that the alt version will run
the self-test but the original will not and to see the README.md for
more details.
The version that compiles with clang now will run some of the self-tests
right. Unfortunately it does not run them all okay. Because of this I
have decided to make the clang compilable version the alt code and the
one that will work with compilers without clang's defect (or this
specific defect amongst others of clang I might say) is the original
(well the fixed original).
The clang version fix has something of a hack in it to make it work
somewhat but it's not ideal. This is another reason that I have for now
moved it to the alt version. I explain more in bugs.md.
The Makefile has been updated to note that the code requires a compiler
that will let one have non-standard types of args to main() and that if
one does not have such a compiler they should use the alternate code
instead.
In time I hope to look at this more and then we might not have to have
two versions but we shall see.
In order to not require being compiled as 32-bit the 'long*E' has to be
a 'int*E'. This version works fine and I wonder if it should be the main
version with alt being for clang that does not work fully: not sure.
Updated bugs.md with more information (what I came up with yesterday and
today).
As a new issue was opened in the mkiocccentry repo I will be doing less
here for a while most likely but there probably will still be some
commits. I felt however that this was a needed commit to make as it was
left unfinished yesterday. I actually can provide a bit more information
on this entry but for now it'll suffice. The additional information has
to do with what system() is passed.
Yesterday I noticed that Timo wrote directly to me in his remarks and I
wanted to address this by adding a link to myself (which is what is
being done with all winners being referred to) but this naturally meant
I should format fix the file too. I am very touched by this especially
as 2019 was a very hard year for me and I didn't even think I was going
to participate in that year (did in the end and didn't win but funnily
enough some of my entry ideas actually won though with some differences
of course) so I wanted to address it now. I might end up changing my
name to my full name but I want to keep it as close to as possible
(format fixed and links added notwithstanding) first to see how it
looks. Thank you Timo! It means a great deal to me.
In the paragraph to me Timo wrote about his 2018 entry and I linked to
that too.
I changed another winner Timo mentioned to be a link (the winner in
winners.html as well as the winning entry referred to are now both
links).
Add some links and other format fixes.
Added INABIAF section to both the README.md file and bugs.md.
Typo fixes or at least adding a word here and there to make certain
things a bit clearer.
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).
I can now report happily that the program works as it was thought to -
both modify the binary and run it. A problem was that it used to call
main() infinitely (seemingly) call main() recursively but this was
causing a problem. It had to be (as I did some while back) moved to a
new function which is not recursive. My guess is that in the past it was
okay due to exit() but I don't know if this is true or not. So what
could be done?
We have to make sure we have BOTH the file descriptor AND the mmap()d
memory close()d and munmap()d as otherwise we would get a text file busy
error. Then we simply call execv() again. I didn't change it so that the
earlier call to execv() is no longer called because I didn't want to
break anything even though at that point M is actually empty.
The astute programmer would observe that the execv() call is slightly
different: don't use M as the path but rather k[1]. Why? Because
initially M is empty but after the function is called it ends up being
something like '.anonymous.ten134517173' but this file never exists. If
you observe even no file is created (or so it seems) as only cpp is
used, not cc (I'm not actually clear what the purpose of that is). The
mmap() call is important of course as is the open() call as one of the
parameters of mmap().
Is this a workaround? Perhaps in a way but it's the only way it'll work
that I can think of as munmap() and close() must be called lest we get a
text file busy error and only then can we call execv().
Removed cpp.c and cpp make rule.
Add back cpp.c which is a C pre-processed version of anonymous.c. Added
comments and tried to format it some. Perhaps I should use a formatted /
de-obfuscator from some years ago in the IOCCC (by Dave Burton) but I
didn't think of that until much later on: I'll consider it another time.
The Makefile builds cpp by default. Works as well as anonymous.c: will
modify 32-bit ELF binaries in the right systems (it won't touch them in
macOS - I pre-compiled anonymous.ten.c as 32-bit ELF in linux and added
it to the repo as anonymous.ten.32 mostly for those who might be able to
run 32-bit ELF binaries but have no way to compile them though maybe no
system has that but it also allows for partly 'testing' the program in
macOS).
Change main target to compile to anonymous and not anonymous_tmp. This
is because otherwise running make would repeatedly try and build it. I
did try changing the target but that didn't want to work possibly due to
the cp updating the timestamp though that's a quick thought in the head
of someone who's been awake too long at the hour.
Instead anonymous.sh is the script to run to 'emulate' the running of
the target program (again assuming that's correct which does seem likely
but is still unconfirmed).
The anonymous.sh script now checks for compiling anonymous.ten.c but
uses anonymous.ten.32 as a backup if it exists.
Update bugs.md and README.md.
Anything else I'm afraid I've forgotten.
As it's uncertain (both to Landon and me) whether it's supposed to
execute programs it is run on or only modify it which it does (if 32-bit
ELF - which is the only kind it's supposed to act on) with my fix (see
README.md for commit ids) I have added a new bug status:
STATUS: might not be completely functional - can you confirm?
and added this new status to this entry. When or if we figure out the
functional status we will remove (if completely functional or we figure
out what's wrong and fix it which of course is the ideal case) or change
(if it is not completely functional) the status. If anyone knows the
functionality status *please* let us know!
I also updated the try.me.sh script to be quiet on make clobber so that
if -m32 does not work nothing but the error message will be shown and if
it does work only the commands and output of the commands will be shown.
In other words make commands are not shown.
By chance I looked at this entry again and it immediately popped into my
head how to get it to work. Except for the one in main() the ints need
to be longs. This will now compile and work as expected both with
64-bit and 32-bit compilation.
Disabled make alt and updated .gitignore.
I've kind of wondered for a while if it's due to Apple's restrictions
against memory protection (in mmap() wrt exec/write/read) and it seems
like that this might be the case either for the Apple silicon chip or
others too (I can only test the M1 chip).
I linked to resources found on Apple's website as well as added a bit of
information I discovered but I think at this time this cannot be
resolved easily or at all because Apple seems to think they know better
than everyone else on certain things and unfortunately they make it very
hard to work round these types of decisions. I will proceed to other
years now, starting with 2013/birken, in the next commits ... unless I
find a typo or something in an earlier year prior to continuing 2013 :-)
Just to clarify it's not that I'm avoiding the README.md files I have
one I'm working on but I got tired of it for the time being and so went
back to 2011/richards for some reason or another.
This includes a minor code change. I believe at this point that it's an
inherent issue of macOS but I might be wrong. I'll certainly look at
this more in the future but I'm going to try and work on the remaining
README.md files first. Time will tell how much I succeed.
The clang issue does have an alternate version which I made a while back
but I added a note earlier in the file that most likely it'll be needed
for clang - depends on the default CFLAGS possibly but for macOS at
least it does not work. I never tested linux but I probably should.
Based on the author's description I made an alt version that should
theoretically work in Windows though of course (thank goodness) I have
no way to actually test it.
Just like with 2011/vik I've only done this because part of issue #1 is
to make entries work on as many systems as possible though it's not
entirely clear to me that 'Windows' should even be considered a 'system'
at all let alone one worthy of consideration :-)
Updated .gitignore.
Cody Boone Ferguson