Although the 'p' macro was used in other places too now it's used in one
place that had been changed to the translation. More will follow in
coming commits soon or if not hopefully later on in the day.
It now uses the G macro that was unused in the fix. I plan to look at
the other macros that were changed to be unused as well. The hope is I
can make it look much more like it originally looked but still let it
work. Last I remember unfortunately it's not simply a matter of changing
that function that uses the macros but it might be worth trying that
again.
Also in this commit I changed the literal "anonymous.c" to be __FILE__
like it was before.
In other words try and make it so that the munmap(),close(),execv() is
like how it was before (comma operator in succession) though of course
the munmap() and close() were not there until yesterday's fix as text
file busy error (ETXTBSY) was not a problem in the past with this entry.
These were part of debugging the reason execv() did not run the target
program but I forgot to remove them once I found out it was a text file
busy error.
Also added to README.md another git diff to try as it might be
instructive.
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.
For some reason the check that exists has opposite meanings in macOS and
linux so instead of checking the status of make I check if the file
exists after a make clobber all.
Using a script running ./anonymous will run the program after modifying
it. This is a temporary workaround and it's not certain when this will
be changed back or fixed if it even can be. I am aware of some things
that might make it work IF it actually IS supposed to run the program
that it's run on (an additional reading of README.md suggests this might
indeed be the case). In any event the entry DOES modify 32-bit binaries
(bit twiddling) and then running the script (made a copy of
anonymous.sh where anonymous.c is compiled to anonymous_tmp) it will run
the program after doing this, assuming that the program to modify
actually exists.
It should be noted that because things have changed so much it is hard
to know if the modifications to 32-bit ELF binaries are correct but if
nothing else the binary will not crash on 32-bit ELF binaries and it
will modify it but still let it run (though from the author's comments
this might not be possible; this cannot yet be confirmed). Leo it
appears wrote the judges' comments so I will try and get more
information from him later on.
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.
Fix typo fix and format fix in 2001/anonymous/README.md.
Improve try.me.sh: test compile as 32-bit anonymous.ten.c and exit if it
cannot be done as it will otherwise not truly work right.
I also observed that this _might_ not be fixed completely. The binary
_is_ modified and _does_ run after execution, will crash on 64-bit
binaries (and it's not supposed to work on 64-bit binaries and probably
anything other than 32-bit ELF binaries) but the author comments are not
entirely clear to me. It might be that the program is supposed to be
run. At the same time though the compilation is unclear to me too: the
entry itself need not be compiled and the binary isn't compiled either
(is it supposed to be?) so why is it there? The program is at least
partially fixed in that it used to crash no matter what and it does in
any case modify the binary which was supposed to be done (and this is
why I'm still unsure about why it does anything with compilation).
Perhaps it's time to bring back the C pre-processed code but I will find
more out in the coming days I hope and if necessary I will add this
entry back to bugs.md and then look at fixing it after some higher
priority things are finished. The higher priority thing in particular
has to do with issue #4 but I have a number of already modified files
that I would like to get committed before I continue on that to make my
repo a clean state. I might or might not do that before but it might be
that there are numerous commits prior to the CSV file being worked on
again.
This was done quite easily with a bit of thought. I generated a script
that could be modified in vim if necessary (as it turned out to be
though some of it could have been generated too but I did not think of
everything at once and it is a hack).
This is how I generated it:
echo '#!/bin/bash' > bin/check_awards.sh ; ( while read -r g ; do echo grep "$g"; done < <(sed -e 's,_,/,g' -e 's/"/\\"/g' tmp/year-auth-prize.csv | awk -F, '{print grep "\x22" $2 "\x22" " " $1 "/" "README.md"}' ); ) >> bin/check_awards.sh
Then I I modified the file (again this was a hack to make it easier and
quicker and better for being tired too) in vim to make the grep use -Hc
so I could pipe it to 'grep :0'. This found the files without the right
award. So the final command was:
sh bin/check_awards.sh |grep :0
though I did have to edit some files several times.
For reference the script has been added to the repo too but with +x
permissions.
This change also required updating the CSV file in tmp/.
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.
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.
Whereas fact() (factorial) is an overflow if n > 12 the Fibonacci is an
overflow if n > 48. In this case it reports an empty string - when it
finally finishes. For instance if you use n = 99 it takes a long time to
finish. Since n == 49 prints an empty value we check for overflow just
like the author did for factorial.
Add compilation of bellard.otccex.c to Makefile; this can be compiled as
64-bit so we no longer specify -m32 in ARCH but instead we do that
explicitly for bellard.c. This way users can at least enjoy the
supplementary program even if not by the bellard.c directly compiling
and executing it.
In order to know what had to change exactly I tested this out (though
it's possible I forgot to initially document changes and so I did not
test everything) and I have documented it in the README.md. The required
changes:
- remove infinite recursion from main(): move the body of main() to
another function.
- add #include <sys/mman.h> for mmap().
Without either this did not work. I also changed (in case of
non-standardised constants) '3' in the call to mmap() to be
PROT_READ|PROT_WRITE but this appears to not be strictly required.
I added the script try.me.sh which has more commands than the previous
try section to show how it works and what changes etc.
Updated .gitignore as the above script creates some.
Make make all attempt to compile anonymous.ten.c: it's an important part
of the program though it can work on other 32-bit ELF binaries.
Update bugs.md explaining why this won't work with macOS.
By instinct I suspected that the reason it did not work fully (some
invocations do work) is that it's being compiled as 64-bit. This proved
to be the case: 32-bit works in full. Thus make alt now compiles it as
64-bit and the default compiles it as 32-bit.
To prevent making the Makefile more complicated for the default (not the
alt) target we add -m32 and the alt does not do anything special.
Updated bugs.md as the bug status and other information about it has
obviously changed. Same with README.md.
Updated .gitignore.
There are a number of improvements in this commit but first: added
missing file status to bugs.md and also note on gets() being used (but
see below).
Format fixes in README.md.
As for improvements the following things were done.
Move the 'try' commands to new script westley.sh. It includes
additional commands and shows what each one is before executing it.
Added westley.sort.c which is based on the author's suggestion of sort
-b which always sorts the input. This was actually westley3.c in the try
section but this has been removed or replaced.
Added westley.punch.c which is also based on the author's comments - it
shows the punch card always. This was also added to westley.sh. Why did
I name it westley.punch.c ? Besides the fact it shows punch cards
there's a silly remark/joke in the README.md about it that answers it. :-)
These updates seem worthy of Brian Westley's final entry and a most
wondrous entry at that!
Format fix README.md.
The author noted some known issues. Marked them as INABIAF.
In this case (first one) I found the author's mastodon handle. Added to
winners.csv and the README.md.
I was unable to test that the program still works. I might test it
another time.
His URL was dead but I found via the Internet Wayback Machine a blog. He
hasn't really updated it (one entry this year) since I think it was 2021
but it's better than what it went to before. He might be on GitHub with
the same handle but I haven't confirmed it so I won't link to it. The
URL was updated in winners.html and winners.csv.
Format fix README.md.
In one case I was able to fix an unsequenced modification but there are
other variables this was not possible to do this time round (it might or
might not be possible at all).
Format fix README.md.
Update bugs.md talking about the fact that this program crashes in some
cases.
Instead of main() calling main() main() calls pain() and pain() calls
itself. This was an attempt to deal with the variable types though might
not be necessary. It can possibly help find the right value however.
Note that there is more dead code added. This is due to the author's
statement (unfortunately not enough information) that one has to fill a
line with doing mostly nothing when calling a function.
Note that this entry is meant to show different output on each
invocation and that still happens. However each line has a pattern that
repeats.
These above points are in the bugs.md as well.
Format fix README.md.
There are some missing files - added to bugs.md. Unfortunately they're
not in the archive.
I'm aware of an issue in the entry to do with more recent compilers. I
will be investigating it in the coming days very likely but it might be
said that this entry does not work at least in part or maybe in whole. I
wrote in the bugs.md that it's in part but now I think on it I think it
doesn't work at all and I'll be looking at it soon.
Updated .gitignore.
Added file that the author referred to and actually gave the contents
of. Unfortunately the missing files were not given.
The author stated this directly. It is noted in the bugs.md file and the
README.
I also included a suggested change by Yusuke Endoh. This is not
necessary for compilers that support -Wl,-z,execstack but not all
compilers do (though the only one I've found that has this problem is
macOS which it won't work under anyway just like -m32 won't which we
also now use).
Added the 'more portable' version by the author. This does not compile
at least under 64-bit linux (not macOS either though of course it
wouldn't work in macOS as if you look at the code you see hardcoded
paths for linux ld-linux.so).
I note that there's a de-obfuscated version on the author's page for the
entry which might give some clues. I might look at it in the future but
it appears that unless someone can provide a 64-bit linux version this
will be one of the entries (now far fewer with many fixes made) that
simply no longer work.
This thus completes for now 2001/bellard even with disappointing
circumstances.
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.
Had to use the Internet Wayback Machine unfortunately.
Format fixed author information in 2001/herrmann2/README.md and
2001/herrmann1/README.md.
No other changes were made in this commit.
The alt code is based on the author's notes. It makes it faster. I
discovered a fun flaw in the change and I challenge (in the alternate
code section) others to find it!
Format fix README.md.
Update bugs.md - this program deliberately crashes if it loses (which it
is tries to do). The author provided a way to fix it. It was uuencoded
but as per discussion on GitHub spoilers are not supposed to be here any
more so I uudecoded it. This feature was also added to the INABIAF
section in the README.md.
BTW: if you're trying to lose and you lose did win or did you lose? :-)
I don't believe I actually need a 32-bit system to test it out so I
might end up trying to fix (more than I already did). I've updated the
bugs.md as the 32-bit requirement seems like it might not be necessary
(if my fix to 2001/anonymous is any indication as with gcc I can use
-m32).
In try section added some things to try.
In INABIAF I noted that the program will also very likely crash if the
program is not given a file name and that it will likely :-) do
something funny if used on itself (at least if compiled with 64-bit -
not sure about 32-bit).
This was a fun one to figure out. There were a few steps. Amongst them
was adding the include for mmap(). Another part that might or might not
be relevant was having main() call a new function rather than main()
itself. This seemingly solved an infinite recursion call to main()
(according to gcc).
I changed the third arg in the call to mmap() to be
PROT_READ|PROT_WRITE. This might not have been necessary as it might
evaluate to 3 which is what it was.
I regret that some macros were removed and some formatting was changed.
This was not intentional but I want to get the fix in and then I can fix
the formatting and macros (or try to - some of it might or might not
cause a problem).
Note that it will crash on any binary that's not 32-bit/x86. In other
words this won't work in macOS unless you have an old enough Mac that
supports 32-bit binaries. With gcc (which is clang in macOS so that
won't work either) one can do -m32 and that's what is done for
anonymous.ten. It probably should be built by default but it's currently
not.
Cody Boone Ferguson