Fix a few things. Now it's in good state. There were some fixes made
already but it still only works for i386 linux (except the supplementary
program can compile and work in modern systems for fun after I fixed it)
and if anyone wants to provide a version for x86_64 linux, for example,
they can do so.
A tip is already in thanks-for-fixes.md so I just referred to that file
instead to not duplicate information (the information in that file is
relevant to the change made already).
The alt code is based on the author's remarks that should allow users
with non-standard systems like DOS/Windows which have conio.h to use
this program, replacing read(2) and write(2) syscalls. It need hardly be
mentioned that I have no way of testing this so it's possible I did
something wrong but it seems not the case (whether anything has changed
since 2006 that might also break it is unknown).
The bug status has been updated both that one bug is not actually a bug
but appeared to be a typo and there also appears to be a missing file
(IMPORT.COM).
There still remains another bug or at least it is thought it is a bug
and this has been added whereas the other one about scripts removed.
This was noted in commit 8741610110 but I
accidentally left it off in the commit.
Add that one may certainly try fixing it if they want for entertainment
value / to challenge yourself (if you think a two second fix is
enjoyable or a challenge :-) ) but it should NOT be committed.
Now it's considered a bug that might be worth fixing, either as alt code
or for changing it to work with more compilers.
I also renamed the status recently renamed just a tad: don't say fix for
all compilers but more compilers as it's highly unlikely one can test
every single compiler. This is the status this entry is classified
under.
Slight update to thanks file about this entry - make it a simpler note
about how some compilers (after fixing it to work at all which I did
quite some time back) will still compile it into an infinite loop but
it's a known issue. Clang in linux, incidentally, does not have the
problem but clang (which is even what /usr/bin/gcc is) in macOS does.
Other fixes in the bugs.md file were made as well particularly updates
to the explanation of some of the statuses at the top of the file.
Rather than have:
STATUS: doesn't work with some compilers - please provide alternative code
It might be better to have:
STATUS: doesn't work with some compilers - please provide alternative code or fix for all compilers
which it now is.
Only one entry had it in so that entry and bugs.md were both updated.
Another entry in bugs.md was modified before and the README.md but the
status was not changed. That will be in the next commit which will be
this retitled one.
This took less time than the previous fix (to let it work with clang)
because after stupidly doing the decryption/encryption manually I had
decided to write a simple program that does it instead.
Now systems won't whine about gets() being unsafe.
The thanks file further documents how this was done and the bugs.md file
no longer has this entry.
The program (and the generated program made by shark.sh) no longer use
perror(3) and instead use fprintf(3) (writing to stderr). This is mostly
because in macOS errno == 0 looks like an error.
Some updates to the shark.sh script were also made.
The bug status has been updated as there is apparently another bug
though I was sure it was solved when I last looked at it. It happens
with and without the above updates. I'm unsure about other things too
but these are not in the bugs.md yet as I'm not even sure what to say
just yet.
Added try.sh script which does some of the commands. However as there is
that bug it doesn't do any comparisons - for now.
If no arg is specified it crashed. If arg was not a number > 0 it
entered an infinite loop. Both have been fixed, exiting 1.
These checks were NOT done in the alt code as that's a copy of the
original code.
Added to the INABIAF that not only is there a way to cheat which was
documented at the time and which I discovered when fixing the code but
there is actually a way that I discovered recently where you can cheat
but it still actually wins! Does that mean it is cheating as well? :-)
Or is it that one cannot actually cheat a cheater? :-) Either way this
felt like a good thing to add to the bugs.md as well.
For both check args.
For alt move main()'s code to new function as some versions of clang do
not allow four args. Instead main() has two args now, the traditional
argc and argv, and the other two are passed 0.
As the definition of INABIAF changed, again, and since it took no more
than ten seconds to fix, I have fixed this entry.
As the thanks file was updated for this some other things that had been
left out were also fixed at the same time as these were already in the
file but not committed. There was also a typo fix in there.
The entries referenced in `bugs.md` now have, below the
"To build:" section, a "Bugs and (Mis)features section text"
that matches the `bugs.md` status.
Several entries had their "STATUS" changed from:
"STATUS: INABIAF - please **DO NOT** fix" to:
"STATUS: known bug - please help us fix":
This was done because, while some of the bugs were minor,
inviting someone to try and fix the issue does nil harm.
In a few cases a more difficult bug was also changed to
the "please help us fix".
While we do NOT want to waste time fixing such entries NOW,
letting others become involved and to try to fix the entry
is a good thing as to encourages people to study the entry
and try to fix the entry. We don't need to accept a fix
that is offered, and of the fix transforms the source in
a less than desirable way, such a fix (if accepted) could
be become a alt source code.
It turns out that putting a / in a level 2 header
makes it hard to link to in some cases.
So instead of using a level 2 header of the form "year/dir"
we use a level 2 header of the form "year dir".
We previously missed making a new form of level 2 header
for 1993/lmfjyh.
We also made a change to the level 2 header for 1984 laman
to see if using space instead of / works better.
As the `bugs.md` has grown, the need to link into a specific
section of the `bugs.md` has become apparent. While there
are links the entry's `bugs.md` section, due to the
complexity of a head such as:
the links within the header will make it hard for
markdown to html to form such links.
Instead the level 2 header has been transformed into:
vvvvvvvvvvvvvvvvvvv--- level 2 header below ---vvvvvvvvvvvvvvvvvvv
^^^^^^^^^^^^^^^^^^^--- level 2 header above ---^^^^^^^^^^^^^^^^^^^
We made a test modification to `1984/laman/README.md` to
refer to this section as:
vvvvvvvvvvvvvvvvvvv--- reference to the level 2 header below ---vvvvvvvvvvvvvvvvvvv
The current status of this entry is:
```
STATUS: INABIAF - please **DO NOT** fix
```
For more detailed information see [bugs.md#1984/laman](/bugs.md#1984-laman).
^^^^^^^^^^^^^^^^^^^--- reference to the level 2 header above ---^^^^^^^^^^^^^^^^^^^
One advantage of the above section is that it contains only
a single link into `bugs.md`.
In particular we use the following string as a link into `bugs.md`:
/bugs.md#1984-laman
We plan to verify that this is the proper way to link into `bugs.md`
after we push this commit.
During these edits, we discovered a set of quasi-duplicated
big entries spanning from 1998 thru 2013. We say quasi-duplicated
because the repeated information was not the same.
We made a guess in `bugs.md` as to which parts were correct,
however our guess may have been incorrect. Therefore, we
preserved the two sets in two files.
The 1st set of 1998 thru 2013 is found in: `bugs-1998-2003-parta.md`.
The 2nd set of 1998 thru 2013 is found in: `bugs-1998-2003-partb.md`.
Please inspect the sets, and if needed, update `bugs.md` as needed.
Please remove `bugs-1998-2003-parta.md` and `bugs-1998-2003-partb.md`
when you are done.
It appears it might not possible to fix the second and third version
that is generated by itself to compile with clang. It _might_ be but it
takes heavy modification. What's more, when I almost had it, it then
caused compilation errors in a different compiler (gcc). I now have a
good idea how to make the code create different functions (see thanks
file for more details on what had to be done to fix as much as possible)
and names and everything else which I might use in the future but for
now it is as good as it can get.
There is a known problem with version 2, namely that SOMETIMES it
segfaults after printing the output. It is hard to know if this should
be fixed but given the complications of this entry (it is truly a
masterpiece as was typical of Brian Westley) fixing it could also break
something else so I have changed it to INABIAF status.
The code that was the alt code now works entirely with gcc! The ver2 and
ver3 do not yet work with clang but the other versions do so it seems
appropriate to make this the main version and remove the alt code and
alt scripts.
I will continue to work on this in between the README.md files but this
feels like great progress and as it was all I felt up to at this time it
is definitely worth the effort and time.
I fixed it ages ago and the only reason it was left in was for warnings
that should be ignored. However since these warnings are now silenced it
doesn't matter any more.
Swap order of alt and original code in build/try sections so that the
original code is suggested second, after alt code, with the bugs and
(mis)features added to the README.md file, pointing out that it'll only
work on VAX-11 / PDP-11 machines. This is added in the bugs.md (it was
actually missing from the bugs.md file).
The alt code (both versions, see below) now have a lower limit on the
microseconds at 500 (still defaults at 10000). This is because anything
much lower and it's nigh impossible to see and in some cases it won't
work at all (at least in the MacBook Pro with the M1 chip).
Added second alt code which is like the first except that once it times
out it starts over.
Running make alt will compile both alt versions.
The gentab.c file that I added (found from the author) and fixed to
compile could not always create code that would compile due to some
characters needing to be escaped like ' and \. These are now escaped if
they are encountered but there certainly could be more that I did not
think of that would have to be escaped.
The alt code has been changed so that in addition to the main feature
working it will also generate ver0 and ver1 correctly; ver2 and ver3
cannot be compiled still. This is not perfect but it is progress. I will
look at this further later most likely.
Added compile.alt.sh to compile the alt code and generate the alt code
generated code. It generates it in the file name form alt.ver[0-3].c and
the code will be compiled as such.
Added try.sh to demonstrate the main (original) program. This is because
there are a lot of commands to try.
Added try.alt.sh to demonstrate the alt program (not trying the ver2 and
ver3, naturally). The rationale is the same as for try.sh.
The Makefile has been updated for these changes.
Updated .gitignore as a number of new files will be created when running
compile.alt.sh.
The bugs.md has been updated as there has been some progress made. The
hint was removed at this time as it's not applicable now; the problem of
main() args not being allowed is no longer true. However the status line
has not been updated because the root of the problem is this. There are
currently no hints because I do not have any yet.
The thanks file has also been updated for the new scripts as well as the
situation being changed.
Unfortunately the fix to let the main program compile with clang even
breaks some versions generated (see compile.sh) in syntax error so even
gcc cannot compile those. Therefore it's now alt code. The alt version
will compile with clang and the main feature of the program will work
but the program cannot generate every version of the program.
The bugs.md and thanks-for-fixes.md have been updated along with the
README.md.
In the README.md there is a different heading level for the alt code
sections to compare to another as we try and figure out what heading
levels to use.
I changed the delay to 0 in the compile.sh script but one can set it to
another value if they like.
This entry will have to be worked on more at another time.
What this means is I changed the heading level from 2 to 3 of the STATUS
lines (under the entries) so that it shows that the status is for the
respective entries.
This was thought of when I was working on moving the bugs/(mis)features
of the entries of 1980s to bugs.md (as in making the README.md files
refer to the bugs.md but not include the details, just the status) and
noticed that it just didn't look quite right. Hopefully this improves it
just a bit.
Having to click on the links in each README.md file will have to be done
to verify the links work but it appears to be in the form of:
/bugs.md#YYYYauthor-readmemd
Looking at the author's remarks (which I hadn't checked yet) I was able
to determine how to get the code to disable warnings when compiling the
generated C code. The text
!.Xop.fssps!.Xop.sfuvso.uzqf!.Xop.jnqmjdju.gvodujpo.efdmbsbujpo
had to be added to the string 'q' and then
system(q-6);
had to be changed to
system(q-69);
to disable the warnings that clang (at least in macOS - not sure
elsewhere) ended up being errors due to the forcing of -Wno-error.
An important point is that the placement of that text does matter due to
the code:
*o=fopen(q-3,"w");
If the file name is not at the end then what will happen is the 'a.c' file
will not be created as the end of the string 's' will not be (when
decrypted) 'a.c'. At that point the compilation would fail as there is
no file to compile that is created. Thus the end of the string has to
be:
!.Xop.fssps!.Xop.sfuvso.uzqf!.Xop.jnqmjdju.gvodujpo.efdmbsbujpo!b/d
With this the file can be generated and compiled with both gcc and clang
even if -Werror would otherwise cause problems.
The alt code has been removed and the Makefile no longer has alt code
nor does it have the 'a' rule.
Format fix the README.md file including removing some '\'s at end of
lines (in the remarks).
Document feature that if the arg is a large number or < 0 (the latter of
which I discovered a few minutes ago as I was working on this) it will
enter an infinite loop trying to compile code that has syntax errors.
This was noted by the judges at the time so it is not a bug but a
feature. This has been added to the bugs.md and the README.md file.
It was documented that the program detected invalid input but it
actually (now - it used to work) printed in an infinite loop 'You:'. Now
doing invalid input forfeits the game which is better than flooding the
screen. It is not yet clear if it should act like you put in 99 (see the
README.md for details) so this is in bugs.md just in case. If it is
supposed to just skip a move then this can be fixed but otherwise it can
be removed from bugs.md without any change in the code. This fix applies
to both versions, the one with the board display and the original entry
(with contest restrictions on size of code).
When trying to get this entry to work for modern systems I ended up
replacing some macros with what they translated to. This meant that it
did not look as close to what the original entry looked like.
There was another change as well in this commit. The variable that is
the file to open was changed to a FILE * instead of an int. Although it
did not crash after the change I made when trying to open the file (see
below for why this was done) it's not strictly correct either in modern
systems (and maybe not in older systems either though it clearly
worked).
Now as for why the fix to being able to open the file: it's because at
the time I was trying to get it to work with modern systems even though
the author stated that it was designed for i386 linux. Doing this proved
possible with a number of other entries but in order for it to even get to
that point this change was necessary. According to Yusuke Endoh, it did
work with an emulator so that was not strictly necessary but I did not
know this at the time and it seems better that at least it can open the
file even if it won't completely work due to the way it is designed. It
seems better too as it might help provide a way to get a version for
64-bit systems.
The thanks-for-fixes.md and bugs.md files were updated on account of
these changes. The bugs.md file also includes why it was changed when
the entry is designed for i386 linux: besides the fact that I fixed the
supplementary program that did not work at all. It seems that, according
to Yusuke, that both works in an emulator but this way at least one can
enjoy the supplementary program in modern systems too and the entry
itself is a bit more correct.
The bug status of this entry changed as well. It now has both INABIAF
but also asking for alternate code. Why this is is explained in the
file: it does indeed seem to not make sense but the rationale is
explained there.
Cody Boone Ferguson