The 64-bit code binaries have been renamed to .alt: anonymous.ten.alt
and anonymous.bed.alt. This is because it's theoretically possible that
they are not compiled as 64-bit binaries (though how this might be I
cannot think of at this time) and in any case they are alt builds
(though they use the same source).
In the case the -m32 fails (whether due to compiler[0] or no access to
32-bit binary compilation) make alt will be used with warnings that the
entry cannot work with them. The reason these are built as .alt and not
the original is to be clearer whereas in other cases (like
1985/sicherman) the point was just a backup plan in case a compiler
objects to it. Here they must be compiled as 32-bit ELF binaries (though
we cannot check if they are ELF - at least not easily and in an entirely
portable way - we can at least determine if they compiled as 32-bit) so
the alt builds are set to be .alt in filenames.
The try.sh script has been updated for this and in the case. However
this file needs to be looked at again and will be later. The purpose of
this commit was to resolve another issue that is in the todo file (this
is not yet done and might or might not be done later today).
There is one exception that I'm aware of and that is the U macro (U is
referenced only in strings) and this is because it segfaulted and it was
a minor change so didn't seem worth investigating further, at least for
now (if not for ever).
This feels like a new pull request is appropriate here so although it's
technically the same idea of the previous pull request this is what
should be the final revision (again unless I figure out why U
segfaulted).
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.
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.
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.
We we move 1988-2004 entries from all of a year's winning entries
in a single directory to each winner being in their own sub-directory
under the given year directory.
Cody Boone Ferguson