A problem existed where in a superscript if there is a line immediately
above it the superscript text would cover part of the line and in
subscript the same problem occurred with the line below it.
This change can possibly be improved but it now does not cover text
(though admittedly I did not test the subscript before the change, only
after, but it seems highly unlikely it was not a problem).
Something that has bothered me VERY MUCH for A VERY LONG TIME is that
the honour roll (under my name) was not very humble and in some respects
rather redundant. I have fixed this a great deal and improved the
readability of it too (grammar and so on).
I also added a point about fixing many entries that no longer worked and
I also did this for Yusuke Endoh too as he was responsible for fixing
numerous (at the least) entries that no longer worked (and it should be
acknowledged and honoured just as much as what I did).
The FAQ I improved is related to one of the things that is in the above,
to do with alternate code. It now explains some of the purposes of
alternate code and why (in some cases) alt code was added when it might
or might not be useful (a judgement call that invariably is not always
perfect). It notes that in many cases the alternate code comes from the
author directly.
With these changes a problem that I felt was a VERY BIG problem should
be resolved now.
The entry that triggered the funny warning (-Wdocumentation) was not in
2013/birken but 2014/birken. Thus the -Wno-documentation was removed
from 2013/birken/Makefile and added to 2014/birken/Makefile.
With this commit I believe that every warning that can be disabled has
been disabled in some way or another, though this is with an earlier
version of clang (clang version 17.0.6 but the most recent one is,
according to its website and contrary to wiki claiming 17, 18.1.8, and I
also know that fedora linux clang had more problems).
The warning is also -Wdocumentation:
recode.c:17:7: warning: line splicing in Doxygen comments are not supported [-Wdocumentation]
17 | /\
| ^
1 warning generated.
.. and I guess it's confused by the line splicing, actually, just like
the others as I see more clearly now, rereading the warning message as I
did not use trigraphs.
The warning -Wunsafe-buffer-usage is triggered (iirc) on pretty much
every use of 'char *' and some of the previous commits also had to
silence this warning. It is triggered by clang -Weverything.
That warning is -Wdocumentation:
prog.c:1:1: warning: line splicing in Doxygen comments are not supported [-Wdocumentation]
1 | /**??/
| ^
... and is obviously confused by trigraphs.
The warning -Wmisleading-indentation is nothing but style policing, can
causes unnecessary edits to working code which is error prone itself and
even beginner C programmers can parse it as it's one of the first things
learnt, blocks of code. And if someone can't perhaps they should be
using another language or not programming at all. As for the IOCCC it
would be considered a good thing to be 'misleading' except that it's not
misleading to anyone participating in the IOCCC and certainly not to the
judges if it even is to anyone else.
Having a '\' at the EOL of an echo followed by the rest of the string on
the next line will obviously not work as the '\' doesn't start a new
command but continues it (scripts notwithstanding). I am not sure how
this even got there but it resulted in a very long line of output.
The wrong tools were referred to, likely a yank paste error from
jprint-wrapper.sh (as all three referred to jprint).
These three tools (and jnamval) will be developed (by me and perhaps
partly by Landon) later on, after IOCCC28 (because much more discussion
is needed before they can be developed and because we are trying to get
the next IOCCC running as quickly as possible) so as the comments state,
a different tool is used at this time. The comments, however, note that
it is a hack until the specific tools have been developed and even if it
does not matter that much the right tools should be mentioned.
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.
The code can recursively call main() as long by changing the name of the
argv and by a cast in the call.
Updated Makefile to disable a new warning.
Improved index.html file.
There are places where references to mirror sites should be kept in like
in the FAQ (currently FAQ 6.2 with the title 'May I mirror the IOCCC
website?' and with the named anchor 'mirrors', 'website_mirrors' and
'website_mirroring').
Amongst the changes here is that we do not need to have the hex or html
code (numbers) for open and close parentheses (in links) as there are
names. '(' is & followed by lpar; and the ')' is the same but 'rpar;'
instead. This makes it easier to remember and type and it generates the
same html as well (they are all valid). Now the markdown files are
consistent in this (in some cases hex was used and in others the html
code).
Although many markdown files were updated no html files needed to be
updated as it generates the same html. Even so I ran the appropriate
rules to do so just to verify this.
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.
Several new FAQ entries have been added to discuss some of the details
of chkentry, txzchk, fnamchk, jparse and maybe others that are related
to the rules and guidelines (and in particular rule 17 and how to
package submission tarballs). As there are new FAQ entries on these
(which is much of what was in the guidelines) the guidelines have been
shortened for these additions.
Looking over the rendered html files it seems okay but I believe that
these entries are works in progress and not complete.
For reference the new FAQ version is 28.0.3 2024-07-27 and the new
guidelines version is 28.11 2024-07-27.
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.
This FAQ was added as part of updates to bin/index.html. I did notice
that there are some inconsistencies with formatting in some FAQs
compared to this (and others also). The example here is that for JSON
members it would be better to use inline code blocks than italics but
some use italics instead. There are others as well. I did look at the
format and the links in this updated FAQ but the format inconsistencies
can be addressed another time - after it is clear that new FAQs will not
have to be added. Even so this FAQ that was added here could also
possibly be improved further - also later on.
The bin/index.html updates need to be more thoroughly checked as part of
further documenting the newer tools (and any additional ones that might
be added) but there should be some improvements as well. This required
check will also be done later on.
The fields are now in the order that the mkiocccentry tool writes them.
A brief note on how to verify that the .auth.json and .info.json files
are valid JSON (not valid according to the IOCCC rules but valid JSON)
is at the end of each of these FAQs. Given that there are numerous FAQs
on different JSON files it seems like that it might be better to have an
entire FAQ on this (it links to a subsection in an FAQ about another
kind of JSON file). Where this might go is unclear to me so it has not
been done yet.
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).
In the years 1991, 1992, 1993, 1994 and 1995 the README.md/index.html
files referred to the UUCP for mail with the text:
For those who appreciate a bit of Internet history, this is how
people used to contact the IOCCC in this given year
and I added to it the text:
via Unix to Unix CoPy (UUCP)
where 'Unix to Unix CoPy (UUCP)' is a link to 'complete' the history.
Improved wording of some of the titles.
Added div ids to each guideline so that we can link directly to them if
necessary.
The code block examples now specify a language so that when language
highlighting is available it will show up better. I added this for those
that are not wanted and those that are in the hopes it will stand out
more.
I added a guideline that for italics one should use underscores (_) as
using single asterisks is known to cause some parsers problems (and this
goes more so, perhaps, when it is bold italic text which would otherwise
be three asterisks in a row). I first became aware of this from a
document on some markdown parsers and it seems like a good idea to note.
Added that it is preferable and easier to use markdown links if possible
(along the lines of how it's easier and preferable to use inline code
blocks instead of spans). This would also help with consistency.
Typo fixes (some in code blocks, perhaps some outside as well).
For tabs/spaces discussion I added a tip for vim users. Maybe this
should be in the FAQ instead but I am not sure.
Move rule about not including literal parentheses in markdown links to
right below the rule about not ending markdown links with '))'.
This is so one can see what the originally published code did. The
index.html has a bold important note that one should NOT send an email
to the address as it is not only no longer necessary but it is not known
if it is still valid. Unlike the index.html where the email was
omitted/redacted the alt code still has the email as the original code
as it is an exact copy thereof, including the typos in it.
Rebuilt .entry.json and index.html.
Updated .gitignore.
For 1993/ant it clarifies (even though the extension of the file
probably would suggest it) that the man page is in text format.
For 2020/endoh2 there were some mistakes introduced with the renaming of
spoiler to other things.
Rebuilt the .entry.json and the index.html files for both.
Rebuilt 2020/endoh2/obfuscation/index.html.
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.
With the exception of 1992/nathan/index.html the entries of 1992 should
all be okay. The reason nathan cannot be done yet is some things have to
be decided first.
This commit fixes:
1992/marangon/index.html
1992/vern/index.html
1992/westley/index.html
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.
For fun more strings have been added and the dictionary constructed with
mkdict.sh now uses index.html as well.
Some fun anagrams that might amuse some people, some from the program
and some that I noticed:
free software foundations:
foundation was set for free
foundations for free waste
unix international:
relaxation unit inn
nun relaxation in it
inline no tar at unix
bill gates:
stale glib
free software foundation (software):
routine and waste offer of (software)
idea for fun software note
microsoft conspiracy:
try ansi op forms ioccc
any op first forms ioccc
international microsoft conspiracy:
first conspiracy container main tool
force locations contains primary tin
but there are plenty others to find with the script and otherwise.
The fixes in bin/README.md include typo fixes, link fixes, format fixes
as well as adding a couple terms that are now used by the IOCCC
(submission and submitter).
The typo fixes in bin/csv2entry.sh were deemed worth putting in this
commit as a lot of the changes in the document are related.
The Makefile rules now have a comment for what they do. The help rule
has not been updated.
The bin/README.md has had some format fixes and some typo fixes as well.
Rebuilt bin/index.html but these two files will have to be checked more
thoroughly later.
The variables CSV2ENTRY and ENTRY2CSV have been added for the new rules
that run the new rules, csv2entry and entry2csv, respectively, according
to the log in 097dd49cc7.
The rules have been added to .PHONY (thinking about this quickly I
believe this is correct but if not it can be corrected) but not make
help as I am not sure where in that rule they should be and I am also
not sure what should be said even as a summary. The rules have a comment
for which tool it runs but it also does not have a summary as I am not
sure what it should say and I do not currently have the time to look
into it.
With this commit it is now easier to run these tools for testing and
otherwise.
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.
It is preferable that unobfuscated code is by the author if they have
(and many have done exactly that).
It would also be preferable to include the author or authors of the entry or
entries if at all possible.
This update includes a link to how to find more information about an
author and I think that FAQ was slightly improved as well.
This solves a problem with smaller screens where the code would wrap to
the next line which ruins the formatting of the code on smaller devices.
A downside to this is that it makes it not fit on the screen but since
it technically did not fit on the screen before and this way line breaks
are not added this seems a much better way. It also will mean we
shouldn't need to try and fix all the other long lines in code blocks
(which not only can be problematic but in some cases it can be wrong -
plus it is taking too much time away from moving from entry to the next
entry to the next entry).
This code was found on the author's web page about the entry and has
been added as prog.alt.c. I added the try.alt.sh script as well.
Manifest updated and rebuilt .entry.json and index.html files.
The previous url was the GitHub url but he has his own domain. The
alt_url is his article about the winning entry of his (of course if he
wanted something different he could do that but it's a good enough guess
for now).
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.
Also removed what seems to be unnecessary quotes, much along the lines
in some FAQ links (that will be having the quotes removed).
Added SECURITY.md to bin/md2html.cfg and updated bin/gen-top-html.sh to
build SECURITY.html. The configuration can be improved for keywords and
other things and the file is not linked into the website either but
presumably it should be.
These are very detailed as they are very important parts of the
mkiocccentry toolkit. The guidelines will likely refer to these for
those who want to know more details but that is for another commit.
In case someone wants more of a challenge in a subsection of the judges'
remarks it has the notice about trying to figure it out by looking at
the code and only (unless they are not looking for an additional
challenge) if they get stuck should they come back to read the author's
remarks.
This includes updates from a recent change in txzchk and more details
about the tools and what they check (warnings and errors) and how to use
them individually.
This does need to be reviewed further, possibly being shorted or
referring to an FAQ, but it's a good start.
The rules had a typo fix as well.
Cody Boone Ferguson