Some bug statuses have been changed so the bugs file was also updated
(some removed, some added).
The manifest of 2004/hibachi was fixed some.
The alt_url of 2004/gavare was fixed which required a rebuild of
authors.html.
For 2004/gavin a proper link to QEMU was added. It strikes me as it
possibly being a good idea to have an FAQ about QEMU (as it is not just
2004/gavin that might benefit from it) but I don't know and in any case
I have zero experience with it.
The entries 2004/gavare, 2004/gavin and 2004/hibachi have been checked
for format / display issues. This would suggest that the next entry to
look at is 2004/hoyle.
This includes some notices to those who wish for a greater challenge.
In the 1998/schweikh3 the man page (and its copy to demonstrate the
entry) have been updated slightly but only in comment (move 'or' from
the command suggested to render it in text to its own line before the
next command also in comment).
The bugs file was updated for an entry or two.
That is make inline code blocks to help them stand out a bit more
(previously they were just normal text).
Another entry in this file just linked to another entry by the same
authors and not even to the discussion in the bugs file but just the
source code. This has been corrected too.
The manifest was updated for 1994/tvr. Rebuilt .entry.json and
index.html.
Bug status changed in 1994/tvr as well. The judges noted that it has an
incorrect result in some cases but the author actually noted this as a
feature so it should not be fixed. Other fixes/updates were made in the
bugs file as well.
A number of other entries of 1994 had minor fixes (formatting, links and
similar things).
The unobfuscated version was recently provided by the author so this is
no longer an issue.
A code block in the INABIAF was changed to a quote as it's not code but
something the author wrote.
This entry's index.html might not be done as a question also has to be
addressed before the manifest can be fixed.
The text 'If you want to try and fix this (mis)feature, you are welcome
to try' was problematic because these things are not (mis)features but
bugs. Thus it now reads '... fix this, ...'.
Also in one case that was noticed it was not actually anything that
should be fixed at all as they were documented features, not bugs.
This 'bug' was not actually a bug but an improper reading of the author's
remarks. Upon another read later on (today) it became clear what
the author was getting at. It is not what happens upon execution but
rather the layout of the code: if the alternate code (the US specific
version) is a one line of 160 characters and your terminal wraps at 80
columns it will spell out (over two lines):
mainland America
The westley.alt2.c is exactly this. It can be compiled if one has gcc or
a compiler that does not have the limitations of arg types to main()
that clang has by using make alt2 (not make alt as it would fail for
clang but people might want to use the alternate code and in fact the
try.sh script does this) but it has the original limitation that one
needs to have a terminal that wraps at 80 columns (since it has to be
the same length of code). But as that size is not that common nowadays
(and in most cases one would have to resize their window) it's mostly
for show.
Updated manifest, rebuilt .entry.json and index.html.
Updated bugs.md and rebuilt bugs.html.
Instead of code blocks the bug / (mis)features statuses are quoted
rather than in a code block. In the case that there is more than one a
line break was added at the end of all but the last one.
A bug status was renamed to be slightly more correct (maybe more than
one was renamed for the same purpose but at least one was).
The bug statuses in the quotes are now bold to let them stand out
better.
The location of the link is in the About menu under the 'Contacting the
IOCCC' and above 'Thanks for the help'. At first I had it at the very
bottom, under 'IOCCC markdown guidelines', but it seemed better to have
it closer to contacting the IOCCC. This is the same location in the no
JavaScript menu (which, for those who do not know or forget, is not a
requirement except for some screen sizes).
The top level Makefile has a new 'security' rule. Updated make help.
Typo fixes in make help.
SECURITY.html has had a few updates as well: change the wording of entry
code is unsupported (it now says 'ALL CODE IN ALL IOCCC ENTRIES IS
UNSUPPORTED!!') and it now links to the mkiocccentry repo and how to
report a possible security vulnerability in that repo; as that IS
supported - and since there was reference to discussing security
concerns is in SECURITY.html - even though the entries will not receive
security updates - it seemed a good idea to have a link to report such
security issues in the mkiocccentry repo. Perhaps the FAQ needs to be
updated for this too.
The change made was incomplete with the other changes in the commit that
addressed the other bug status added (and the gets(3)/fgets(3) one that
was modified).
An additional look shows that the gets(3) call is for the dictionary
file. It is highly unlikely (though not impossible) that the dictionary
file would ever have a line 256 in length and this as well as because it
was documented is why I changed the buffer size back to the original.
The bug status does still suggest it would be nice if fgets(3) could be
used but it also lists the bugs and limitations the author stated in the
first place which actually does refer to the 256 limit.
I moved the notice to those who want a challenge up a bit in the
README.md file to be right above obfuscatory notes rather than before
those notes get into the details.
The unobfuscated code, which was put in deobfuscated/, has been turned
into alt code. In one case the already existing alt code was made alt2
and the unobfuscated code was alt. In the case of the ones with two C
files there, the one that did not require modification (to compile in
modern systems) were used as those are original.
In a few cases these changes suggested additional files: a test suite
Makefile for the alt code, a try.alt.sh script and maybe some other
things besides.
The bug status was updated for 2015/howe with a known bug: in particular
the test scripts do not work (at least not completely).
In the manifest all references (except for a file name that has not been
renamed - at least not yet) of 'deobfuscated' to 'unobfuscated': a minor
detail that might not matter much but it sounds ever so slightly better
(maybe). These other entries that had an entry_text change were
1995/garry and 2020/endoh2. Rebuilt .entry.json and index.html files for
this (and in the case of the moved code the index.html files also had to
be changed for that in addition to the Makefiles).
In most cases the word was changed to 'obfuscation' as it was about
obfuscation, not deobfuscation. In some cases like 1995/leo since the
file was (in 1995/leo) about a secret switch it was changed to
'secret.md' (and 'secret.html') but there were others like that as well.
One entry had the words 'spoiling the size rule' but this had been
changed to 'deobfuscating the size rule' which was obviously wrong.
In the latter YYYY/README.md files the judges had written after some
entries (brief summaries) '...
...We'll stop spouting spoilers now. Have fun exploring all the
entries!
but that was changed to:
...We'll stop spouting deobfuscation information now. Have fun
exploring all the entries!
which wasn't really about deobfuscation but just a brief summary of what
the entries did.
And in the most problematic case (at least for me :-), 2018/ferguson) I
had put a joke in:
... but it's the only Easter egg I won't spoil
but it was changed to 'won't deobfuscate' which not only is not what it
is but it spoilt the joke.
In some cases the word was changed back to 'SPOILER' (or similar) but in
most cases not. I believe it should be better now. There are some
caveats, however, as below.
Although make find_missing_links is okay I do not remember if this will
catch links that refer to '%%REPO_URL%%' or other pandoc tokens. This
means I might have to go back to some earlier years to verify links are
okay. That should not take that much time I hope.
It might also be that some wording can still be improved some but it is
hoped this will be discovered when checking links and looking over the
manifest (which obviously changed).
There were tabs in the part of the file (copy pasted in fact) that was
regenerated each time and I converted them to spaces. Doing a git add -u
and then trying to rebuild bugs.html did not seem to update the file and
since it had in the past I hope this solves the problem.
The `bin/pandoc-wrapper.sh` tool will use `expand(1)` to expand
leading ASCII TAB characters into multiples of 8 ASCII space
characters on all markdown data before piping it into `pandoc(1)`.
Thus, any leading ASCII TAB character in markdown files will be
automatically converted into spaces using 8 character tabs.
Changed `bin/pandoc-wrapper.sh` VERSION from "1.6.3 2024-06-22"
to "1.7 2024-06-22" to preform the above.
Perform `make www` to perform the above and test under macOS.
It turns out that only one other HTML file was impacted: `bugs.html`.
All other leading ASCII tab characters have been rendered
[Mostly Harmless](https://en.wikipedia.org/wiki/Mostly_Harmless). :)
While not strictly necessary, replacing the two ASCII tab characters
in the markdown copyright comment makes it easier to detect problematic
TAB indentation within markdown files.
After this commit, only 90 markdown files have leading ASCII TAB
characters. And again, while not strictly necessary, we can consider
running expand on those 90 markdown files to see what effect that
might have on the HTML files they produce.
Replace leading ASCII TAB characters with multiples of 8 ASCII SPACE
characters (the default action of the `expand(1)` tool) might have
an negative effect on some HTML formatting where **hack-a-round**
formatting was attempted to fix broken indentation caused by
problematic ASCII TAB characters.
Think of this as a baseline for evaluating leading
TAB characters within markdown files.
TODO: Consider either using `expand(1)` to replace leading ASCII
TAB characters with multiples of 8 ASCII SPACE characters AND/OR
modifying the appropriate `bin` tool to convert leading ASCII TAB
characters into multiples of 8 ASCII SPACE characters.
I believe now that it is in good order except for a strange indentation
issue in the index.html file in some code blocks that presumably has to
be fixed with CSS.
The bugs file was also slightly updated.
My original fix no longer worked, at least with clang in some systems,
because of more strictness in the compiler wrt implicit ints. As the
code does not use the Makefile but rather 'cc' (and in an unusual way)
'main()' now has an explicit int.
Also, what was previously documented as a bug to be fixed has been
changed to INABIAF as it was documented already. Thus it should not be
fixed. In fact the judges originally noted that if one specifies the
triggering input they should expect an infinite loop and compilation
failure.
In the case of this entry, it is so screwy that having the CFLAGS
conflicts with the -traditional-cpp option in some systems. Thus the alt
rule has ONLY the -traditional-cpp option. The thanks file notes this
oddity and how to view the diff between the original and the alternate
code.
Also the bugs file was changed to be worded like the README.md file.
The index.html file was improved for the fix to the Makefile (for the
alt build) and it also links to the specific lines in the code on GitHub
(see the index.html file how it talks about specific lines in the
judges' remarks).
It should be 'Location of winning authors' (as it is now) but by mistake
there was an extra space ('Location of winning authors'). Obviously
this is a huge commit as every html file with a menu (almost all) had to
be updated.
A few page names were changed and menu link (titles) were changed too.
By page names it means either DESCRIPTION or HEADER_2 in
bin/md2html.cfg. Although it looks better and is more consistent, there
might be one or two that can be further improved.
Naturally every html file that is markdown based was updated.
In some pages at the top it had 'and' but in the menu it had instead a
'&'. The menus (JavaScript and otherwise) now has 'and' to match the
pages. The file nojs-menu.html has been checked for broken links and
indeed one at least was fixed. Very few top level html files need to be
checked now. Some that are entirely generated should be okay but links
will still be checked to be sure.
Some cases of '(Mis)features' from the previous commit were also
corrected to '(mis)features' as this is also part of menu and page
consistency.
The files markdown.{md,html} have had the menus updated too but there
are some other changes that were works in progress. This file is not
thus completed but will be sometime soon.
This commit changes inc/md2html.cfg also and it is done to make the
header (under the line 'The International Obfuscated C Code Contest')
match the header in the bugs.md file, in case. Updating bugs.md is not
necessary. A keyword was also added to the html file, mis-features,
along with the already existing misfeatures.
The other one cannot be restored or at least should not be as it floods
the screen in an unsuspecting way. If no arg is specified though, it now
will likely crash (previously because of the use of argv[1] later in the
code but now to prevent the code from flooding the screen if the number
is < 0).
The bugs.{md,html} files, 1984/laman/README.md (and index.html) file and
thanks files were updated. The thanks file has some additional fixes
that were already in place but are relevant to this commit.
Regarding use of `temp-test-ioccc` in current repo files:
We will ignore files under `tmp/` as they are going away.
We will ignore files under `bin/` as they will have their default `REPO_URL` value changed during the later parts of the **Great Fork Merge**.
We will ignore `*.html` files as the above changes to `bin/` tool will also change them during the later parts of the **Great Fork Merge**.
We will ignore `sitemap.xml` as the it will change during the later parts of the **Great Fork Merge**.
So this leaves for our consideration the files printed by this command:
```sh
find * -type f ! -name '*.html' ! -name sitemap.xml ! -path 'tmp/*' ! -path 'bin/*' -print0 | xargs -0 grep -l 'temp-test-ioccc'
```
We see 5 (3 sir), 3 cases:
* README.md index.md
The reference to `temp-test-ioccc` will be removed when a given section goes away as part of the later parts of the **Great Fork Merge**.
Nothing needs to be dome here other than to add some **XXX** comments to help remind us of what needs to be done in later parts of the **Great Fork Merge**.
* bugs.md faq.md news.md var.mk
The use of `temp-test-ioccc` is outside of a blob.
Here `https://github.com/ioccc-src/temp-test-ioccc/` may be be replaced by `https://github.com/ioccc-src/winner/` in anticipation of the **Great Fork Merge**.
There is an exception: The historic discussion abouts the history of the `temp-test-ioccc` repo needs to retain their `https://github.com/ioccc-src/temp-test-ioccc/` strings in `faq.md` and `news.md`.
* 2005/sykes/README.md
The markdown links that start with `https://github.com/ioccc-src/temp-test-ioccc/blob/master/` should instead start with `%%REPO_URL%%/`.
After the **Great Fork Merge**, the `%%REPO_URL%%/` value will refer to `https://github.com/ioccc-src/winner/blob/master/` instead.
* 2020/ferguson1/snake.1
There is not a tool to "pre-process" cat pages like there is for markdown files: no should there be.
The cat page refers to a markdown file when instead it should refer to a HTML page.
In this case we suggest that `https://github.com/ioccc-src/temp-test-ioccc/blob/` be replaced by `https://www.isthe.com/`, and `.md` be replaced by `.html` in anticipation of what it will need to be after the **Great Fork Merge**.
* YYYY/entry_dir/*.sh
The shell scripts references by the above command are "helper shell scripts. Like man pages, there is no "pre-processor" for shell scripts, nor should there be.
Looking at these helper shell script files in detail:
```sh
find * -name '*.sh' ! -path 'tmp/*' ! -path 'bin/*' -print0 | xargs -0 grep 'temp-test-ioccc/blob/master'
```
We see that they all make references to `faq.md#something.`.
This is wrong in 2 ways:
0) They should not refer to the markdown file `faq.md` but rather to the HTML file `faq.html`.
1) They punctuate a literal string (with one exception) by adding a final period (".") to a string that requires somebody to copy and paste and exclude the final period (".").
Since these echo commands are suggesting that the user view something within the FAQ, we recommend that `echo "Tip: see https://github.com/ioccc-src/temp-test-ioccc/blob/master/faq.md#` be replaced by `echo "Tip: see https://www.ioccc.org/faq.html#` AND that the final period (".") be removed. Thus they too will anticipate what they will need to be after the **Great Fork Merge**.
Once upon a time after adding the entry to the bugs file it was changed
so that it should be a bug to be fixed and when verifying things since
it was very quick to fix I added it. It now has been restored to the
original.
The bugs file was updated and the thanks file was updated accordingly
along with the index.html and README.md files.
Cody Boone Ferguson