diff --git a/ioccc.css b/ioccc.css
index f03794a27..193634d83 100644
--- a/ioccc.css
+++ b/ioccc.css
@@ -796,6 +796,13 @@ blockquote {
color: DarkBlue;
}
+/* Guidelines / Rules change bar ============================================================================ */
+
+.leftbar {
+ border-left: 4px solid black;
+}
+
+
/* Footer ======================================================================================== */
/* Style footer */
diff --git a/next/guidelines.html b/next/guidelines.html
index cd7ccda48..359b3bccc 100644
--- a/next/guidelines.html
+++ b/next/guidelines.html
@@ -413,14 +413,20 @@ writing by contacting the judges.
IOCCC Guidelines version
-| These IOCCC guidelines are version 28.6 2024-07-06.
+
+These IOCCC guidelines are version 28.7 2024-07-08.
+
IMPORTANT: Be SURE to read the IOCCC rules.
Change marks
-| ← Lines that start with this symbol indicate a change from the previous IOCCC
+
+← Lines that start with this symbol indicate a change from the
+previous IOCCC.
+
Most lines (we sometimes make mistakes) that were modified since the previous
-IOCCC start with the | symbol.
+IOCCC start with a solid 4 pixel black left border (or, in the case of a code
+block, just a vertical bar).
ABOUT THIS FILE:
@@ -439,39 +445,68 @@ guidelines..
WHAT’S NEW THIS IOCCC
-| This IOCCC runs from 2024-MMM-DD HH:MM:SS UTC to YYYY-MMM-DD HH:MM:SS UTC.
-| XXX - date/time is TBD - XXX
-| The reason for the times of day are so that key IOCCC events are calculated
-to be a functional UTC time. :-)
-| Until the start of this IOCCC, the IOCCC rules,
+
+This IOCCC runs from 2024-MMM-DD HH:MM:SS UTC to YYYY-MMM-DD HH:MM:SS UTC.
+XXX - date/time is TBD - XXX
+
+
+The reason for the times of day are so that key IOCCC events are calculated
+to be a functional UTC time. :-)
+
+
+Until the start of this IOCCC, the IOCCC rules,
IOCCC guidelines and the tools in the
mkiocccentry repo, should be
considered provisional BETA versions and may be adjusted AT
-ANY TIME.
-| The submit URL should be active on or slightly before 2024-MMM-DD HH:MM:SS UTC.
-| XXX - date/time is TBD - XXX
-| The IOCCC rules, IOCCC
+ANY TIME.
+
+
+The submit URL should be active on or slightly before 2024-MMM-DD HH:MM:SS UTC.
+XXX - date/time is TBD - XXX
+
+
+The IOCCC rules, IOCCC
guidelines will be available on the Official IOCCC
website on or slightly before start of this IOCCC. Please check
the IOCCC FAQ about how to submit to see how
to submit entries, on or after the start of this IOCCC, to be sure
you are using the correct versions of these items before using the
-IOCCC submission URL.
-| The Rule 2a size has increased from 4096 to 4993 bytes.
-| The Rule 2b size has increased from 2053 to 2503 bytes.
-| The new default way to compile submissions: -std=gnu17 -O3 -g3 -Wall -Wextra -pedantic. See below for more details about the example Makefile
-for more help.
-| Submissions are in the form of a single xz compressed tarball.
-| To assist in the formation of the xz compressed tarball for submission, use the
-mkiocccentry(1) tool as found in the mkiocccentry repo.
-| Rule 17 has been significantly modified
-to account for the new mkiocccentry repo tools.
-| An example
+IOCCC submission URL.
+
+
+The Rule 2a size has increased from 4096 to 4993 bytes.
+
+
+The Rule 2b size has increased from 2053 to 2503
+bytes.
+
+
+The new default way to compile submissions: -std=gnu17 -O3 -g3 -Wall -Wextra -pedantic. See below for more details about the example Makefile
+for more help.
+
+
+Submissions are in the form of a single xz compressed tarball.
+
+
+To assist in the formation of the xz compressed tarball for submission, use the
+mkiocccentry(1) tool as found in the mkiocccentry
+repo.
+
+
+Rule 17 has been significantly modified
+to account for the new mkiocccentry repo tools.
+
+
+An example
Makefile
is now available from the mkiocccentry
-repo and you are encouraged to use
-it.
-| The IOCCC submission URL, when the IOCCC is open, is submit.ioccc.org.
+repo and you are encouraged to use
+it.
+
+
+The IOCCC submission URL, when the IOCCC is open, is
+submit.ioccc.org.
+
HINTS AND SUGGESTIONS:
@@ -513,15 +548,21 @@ point in an ironic way.
entries to attempt to exploit them. We will award ‘
Worst abuse of the
rules’ or ‘
Best abuse of the rules’ or some
variation and then plug the hole next year.
-
| When we do need to plug a hole in the IOCCC rules
-or IOCCC guidelines, we will attempt to use a very
-small plug, if not smaller. Or, maybe not. :-)
-
| There may be less than 2^7+1 reasons why these IOCCC guidelines seem obfuscated.
+
+When we do need to plug a hole in the IOCCC rules or IOCCC
+guidelines, we will attempt to use a very small plug, if not
+smaller. Or, maybe not. :-)
+
+
+There may be less than 2^7+1 reasons why these IOCCC
+guidelines seem obfuscated.
+
Check out your program and be sure that it works. We sometimes make
the effort to debug a submission that has a slight problem, particularly
in or near the final round. On the other hand, we have seen some
of the best entries fall down because they didn’t work.
-
| We tend to look down on a prime
+
+We tend to look down on a prime
number printer that claims that
16 is a prime number. If you do have a bug, you are better off
documenting it. Noting “this submission sometimes prints the 4th power
@@ -529,7 +570,8 @@ of a prime by mistake” would save the above submission. And sometimes,
a strange bug/feature can even help the submission! Of course, a correctly
working submission is best. Clever people will note that 16 might be prime
under certain conditions. Wise people, when submitting something clever
-will fully explain such cleverness in their submission’s remarks.md file.
+will fully explain such cleverness in their submission’s remarks.md file.
+
People who are considering to just use some complex mathematical
function or state machine to spell out something such as “hello,
world!” really really, and we do mean REALLY, do need to be more creative.
@@ -541,16 +583,31 @@ misleading comments and variable names might be a good start.
When programs use VTxxx/ANSI sequences, they should NOT be limited to a
specific terminal brand. Those programs that work in a standard xterm
are considered more portable.
-
| Rule 2 (the size rule) refers to the use of the IOCCC size tool called iocccsize(1).
-
| See the mkiocccentry repo for the iocccsize(1) tool.
-
| To further clarify Rule 2, we subdivided it into two parts, 2a and 2b.
-
| The overall size limit (see Rule 2a) on prog.c is now 4993 bytes.
-
| Your submission must satisfy BOTH the maximum size Rule
-2a AND the IOCCC size tool Rule 2b.
-
| This IOCCC size tool imposes a 2nd limit on C code size (see Rule 2a. To check your
-code against Rule 2:
+
+Rule 2 (the size rule) refers to the use of the IOCCC size
+tool called iocccsize(1).
+
+
+See the mkiocccentry
+repo for the iocccsize(1) tool.
+
+
+To further clarify Rule 2, we subdivided it into two parts,
+2a and 2b.
+
+
+The overall size limit (see Rule 2a) on prog.c is now 4993 bytes.
+
+
+Your submission must satisfy BOTH the maximum size Rule
+2a AND the IOCCC size tool Rule 2b.
+
+
+This IOCCC size tool imposes a 2nd limit on C code size (see Rule 2a. To check your
+code against Rule 2:
+
./iocccsize prog.c
-
| The IOCCC size tool algorithm may be summarized as follows:
+
The IOCCC size tool algorithm may be summarized as follows:
The size tool counts most C reserved words (keyword, secondary, and selected
preprocessor keywords) as 1. The size tool counts all other octets as 1
@@ -560,111 +617,163 @@ before the end of file.
ASCII whitespace includes ASCII tab, ASCII space, ASCII newline,
ASCII formfeed, and ASCII carriage return.
-
| When ‘;’, ‘{’ or ‘}’ are within a C string, they may still not be
-| counted by the IOCCC size tool. This is a feature, not a bug!
+
+When ‘;’, ‘{’ or ‘}’ are within a C string, they may still not be
+counted by the IOCCC size tool. This is a feature, not a bug!
+
In cases where the above summary and the algorithm implemented by
the IOCCC size tool source code conflict, the algorithm implemented
by the IOCCC size tool source code is preferred by the judges.
-
| There are at least 2 other reasons for selecting
-| 2503 as the 2nd limit besides the fact that 2503
-| is a prime. These reasons may be searched for
-| and discovered if you are “Curios!” about 2503. :-)
-| Moreover, 2053 was the number of the kernel disk
-| pack of one of the judge’s BESM-6, and 2503 is a
-| decimal anagram of 2053.
+
+There are at least 2 other reasons for selecting 2503 as the 2nd limit besides
+the fact that 2503 is a prime. These reasons may be searched for and discovered
+if you are “Curios!” about 2503.
+:-) Moreover, 2053 was the number of the kernel disk pack of one of the judge’s
+BESM-6, and 2503 is a decimal anagram of 2053.
+
Take note that this secondary limit imposed by the IOCCC size tool
obviates some of the need to #define C reserved words in an effort
to get around the size limits of Rule 2.
Yes Virginia, that is a hint!
-
| The Rule 2a size was changed from
+
+The Rule 2a size was changed from
4096 to 4993: a change that keeps the “2b to 2a” size ratio to a
value similar to the 2001-2012 and
-2013-2020 IOCCC eras.
-
| Rule 17 (the mkiocccentry(1) rule) states that
-you MUST use the mkiocccentry(1) tool to package your submission tarball.
-
| See the mkiocccentry repo
-for the mkiocccentry(1) tool.
-
| This tool invokes a number of other tools and one, txzchk(1),
-invokes another, fnamchk(1).
-
| Although the mkiocccentry(1) tool will verify everything for you,
+2013-2020 IOCCC eras.
+
+
+Rule 17 (the mkiocccentry(1) rule) states that
+you MUST use the mkiocccentry(1) tool to package your submission tarball.
+
+
+See the mkiocccentry repo
+for the mkiocccentry(1) tool.
+
+
+This tool invokes a number of other tools and one, txzchk(1),
+invokes another, fnamchk(1).
+
+
+Although the mkiocccentry(1) tool will verify everything for you,
you may wish to validate each part individually. As the rules
state, each of these tools have a -h option. However, to help simplify
-matters, we give you a brief overview below.
-
| The synopsis of the mkiocccentry(1) tool is:
+matters, we give you a brief overview below.
+
+
+The synopsis of the mkiocccentry(1) tool is:
+
./mkiocccentry [options] work_dir prog.c \
Makefile remarks.md [file ...]
-
| where the work_dir is a directory that is used to form the
+
+… where the work_dir is a directory that is used to form the
xz compressed tarball that txzchk(1) validates, prog.c is your submission
source code, Makefile is your Makefile, remarks.md is your remarks and
-[file ...] are any additional files you wish to provide.
-
| If the work_dir already exists it is an error.
-
| The mkiocccentry(1) tool will ask you for information about your
+[file ...] are any additional files you wish to provide.
+
+
+If the work_dir already exists it is an error. In the case this happens you
+will have to choose a different directory, or if it is safe to remove, you may
+do so and try again.
+
+
+The mkiocccentry(1) tool will ask you for information about your
submission as well as author details and it will run the iocccsize(1) tool; if
either Rule 2a or Rule 2b are broken,
it will give you the option to ignore them, if you are willing to risk this. The
tool will also do a rudimentary check on the Makefile and run other checks as
well. You can override warnings but doing so puts you at risk of violating
-rules.
-
| On the other hand, some issues are an error and the xz compressed
+rules.
+
+
+On the other hand, some issues are an error and the xz compressed
tarball will not be formed. For instance, if chkentry(1) fails to validate
the .auth.json or .info.json JSON files
that mkiocccentry(1) creates, it is an error and possibly a bug that you
should report at the mkiocccentry issues
page. PLEASE run the
bug_report.sh script to help us out here! See the the FAQ about reporting
-bugs in the mkiocccentry repo.
-
| Assuming that chkentry(1) passes for both .auth.json and
+bugs in the mkiocccentry repo.
+
+
+Assuming that chkentry(1) passes for both .auth.json and
.info.json then the tarball will be formed and then txzchk(1) will be
executed. In this case, there should be no problems as mkiocccentry(1) would
-NOT form a tarball if there are any issues.
-
| txzchk(1) performs a wide number of sanity checks on the xz
+NOT form a tarball if there are any issues.
+
+
+txzchk(1) performs a wide number of sanity checks on the xz
compressed tarball and if any issues (feathers :-) ) are found and if you used
mkiocccentry(1), then it is very possibly a bug in one of the tools and you
should report it at the mkiocccentry issues
page. PLEASE run the
bug_report.sh script to help us out here! See the FAQ about reporting bugs
-in the mkiocccentry repo.
-
| As part of its sanity checks, txzchk(1) will run fnamchk(1) on the
+in the mkiocccentry repo.
+
+
+As part of its sanity checks, txzchk(1) will run fnamchk(1) on the
filename to verify that the name is valid. If this test does not pass, then it
is flagged by txzchk(1) but it is not an error if you wish to ignore it.
Ignoring this, however, risks violating Rule 17 which is a
-big risk. Of course, using mkiocccentry(1) would prevent this from happening.
-
| By default, txzchk(1) will show the contents of the tarball which is
-how the mkiocccentry(1) shows you the tarball contents for you to review.
-
| To help you with editing a submission, the mkiocccentry(1) tool has
+big risk. Of course, using mkiocccentry(1) would prevent this from happening.
+
+
+By default, txzchk(1) will show the contents of the tarball which is
+how the mkiocccentry(1) shows you the tarball contents for you to review.
+
+
+To help you with editing a submission, the mkiocccentry(1) tool has
some options to write OR read from an answers file so you do not have to input
-the information again. To write to answers.txt try:
+the information again. To write to
answers.txt try:
+
./mkiocccentry -a answers.txt ...
-
| Alternatively, if you wish to overwrite a file, you can use the -A
+
+Alternatively, if you wish to overwrite a file, you can use the -A
flag with the same option argument. Be careful that you do not accidentally
-overwrite your prog.c!
-
| To make use of the answers file, use the -i answers option like:
+overwrite your
prog.c!
+
+
+To make use of the answers file, use the -i answers option like:
+
./mkiocccentry -i answers.txt ...
-
| If you wish to manually run the commands you can do so. For instance, to
-check the validity of the tarball
-submit.12345678-1234-4321-abcd-1234567890ab-2.1719574527.txz you can do:
+
+If you wish to manually run the commands you can do so. For instance, to check
+the validity of the tarball
+submit.12345678-1234-4321-abcd-1234567890ab-2.1719574527.txz you can do:
+
./txzchk submit.12345678-1234-4321-abcd-1234567890ab-2.1719574527.txz
-
| Assuming that the tarball exists and is valid, you should see the
-contents of the tarball and the words:
+
+Assuming that the tarball exists and is valid, you should see the
+contents of the tarball and the words:
+
No feathers stuck in tarball.
-
| If you give the option -q it will not report anything unless there
+
+If you give the option -q it will not report anything unless there
are certain error conditions, for instance if fnamchk(1) reports there is a
problem with the filename; if txzchk(1) exits 0 then there are no problems
-detected.
-
| If you wish to run fnamchk(1) directly you can do so like:
+detected.
+
+
+If you wish to run fnamchk(1) directly you can do so like:
+
./fnamchk submit.12345678-1234-4321-abcd-1234567890ab-2.1719574527.txz
-
| Assuming everything is OK, it would show:
+
+Assuming everything is OK, it would show:
+
12345678-1234-4321-abcd-1234567890ab-2
-
| … which txzchk(1) uses.
-
| If you want to validate the .auth.json or .info.json files you
+
+… which txzchk(1) uses.
+
+
+If you want to validate the .auth.json or .info.json files you
should use chkentry(1). chkentry(1) accepts more than one command line form.
If you pass a single argument, it is expected to be a directory that has both
.auth.json and .info.json in it. You can also specify a .auth.json and/or
-.info.json file. An argument of . will skip that file. For instance:
+
.info.json file. An argument of
. will skip that file. For instance:
+
# test entry directory test_work:
./chkentry test_work
@@ -676,108 +785,156 @@ If you pass a single argument, it is expected to be a directory that has both
# run checks on .info.json and .auth.json:
./chkentry .info.json .auth.json
-
| If there is a JSON issue detected
+
+If there is a JSON issue detected
by jparse(8), then there is a JSON
error and chkentry(1) will report it as an error. If the parsing is OK but
there is an issue in one or both of the
JSON files in the context of the IOCCC,
it will report this as an error. Thus, if you were to package this manually
-then you would be violating Rule 17.
-
| At the risk of stating the obvious: you run a very big risk of having
+then you would be violating Rule 17.
+
+
+At the risk of stating the obvious: you run a very big risk of having
your submission rejected if you package your own tarball and there are any
problems. For instance, if chkentry(1) found a problem in your .info.json
file, the mkiocccentry(1) tool would not package it. But if you were to package
it manually, you would be violating Rule 17. But even if
-everything checks out OK you should not expect that everything IS OK.
-
| As you can see, the use of mkiocccentry(1) is HIGHLY RECOMMENDED.
-
| We recommend that you use the
-example Makefile
-from the IOCCC mkiocccentry repo.
+everything checks out OK you should not expect that everything IS OK.
+
+
+As you can see, the use of mkiocccentry(1) is HIGHLY RECOMMENDED.
+
+
+
We recommend that you use the example
+Makefile
+from the IOCCC mkiocccentry repo,
renamed as Makefile of course, as the starting point for your submission’s
-required Makefile. Feel free to modify the Makefile to suit your obfuscated needs.
-
| The rest of these guidelines will assume that you are using some variant of the
+required Makefile. Feel free to modify the Makefile to suit your obfuscated
+needs.
+
+The rest of these guidelines will assume that you are using some variant of the
example Makefile,
-renamed as Makefile of course.
-
| We suggest that you compile your submission with a commonly available
--std=gnu17 (ISO C 2017 with GNU extensions) C compiler.
-
| Unless you clearly state otherwise in your remarks.md file AND put into your
-submission’s Makefile, we will compile using -std=gnu17 -O3 -g3.
-
| It is OK to require your submission to not be compiled
+renamed as Makefile of course.
+
+
+We suggest that you compile your submission with a commonly available
+-std=gnu17 (ISO C 2017 with GNU extensions) C compiler.
+
+
+Unless you clearly state otherwise in your remarks.md file AND put into your
+submission’s Makefile, we will compile using -std=gnu17 -O3 -g3.
+
+
+It is OK to require your submission to not be compiled
using the default -std=gnu17 -O3 -g3 settings. Simply explain why
your submission should not be compiled using -std=gnu17 -O3 -g3 in
-your remarks.md file and adjust your Makefile accordingly.
-
| IMPORTANT NOTE: The use of -std=gnu17 does NOT imply the use of the gcc
-compiler! We often start by compiling using the clang C compiler instead.
-
| You may change the standard under which your submission is compiled
-by modifying the CSTD Makefile variable. For example, to use c17 instead:
+your
remarks.md file and adjust your
Makefile accordingly.
+
+
+IMPORTANT NOTE: The use of -std=gnu17 does NOT imply the use of the gcc
+compiler! We often start by compiling using the clang C compiler instead.
+
+
+You may change the standard under which your submission is compiled
+by modifying the CSTD Makefile variable. For example, to use c17 instead:
+
CSTD= -std=c17
-
| For compilers, such as clang, that have the -Weverything option,
+
+For compilers, such as clang, that have the -Weverything option,
while you may wish to try it, you should look at the FAQ about clang
-Weverything. We do NOT recommend that you put
the use of -Weverything into your submission’s Makefile for the reasons
cited there. This goes even if your version does not trigger a warning as some
-other version might!
-
| You may change the level of optimization and compiler debug level
+other version might!
+
+
+You may change the level of optimization and compiler debug level
that your submission is compiled with, by modifying the OPT Makefile variable.
-For example, to compile without optimization and debug symbols:
+For example, to compile without optimization and debug symbols:
+
OPT= -O0 -g3
-
| There is no real penalty for compiler warnings. Sometimes
+
+There is no real penalty for compiler warnings. Sometimes
compiler warnings cannot be helped: especially in the case of
obfuscated C. :-) So if you cannot easily get rid of a compiler
-warning, try not fret too much.
-
| We LIKE code that has a minimum of warnings, especially under the
-more strict -Wall -Wextra -pedantic mode:
+warning, try not fret too much.
+
+
+We LIKE code that has a minimum of warnings, especially under the
+more strict -Wall -Wextra -pedantic mode:
+
CWARN= -Wall -Wextra -pedantic
-
| The two previous guidelines may be thought by some as being somewhat
+
+The two previous guidelines may be thought by some as being somewhat
contradictory. Isn’t life, and isn’t trying to satisfy “contradictory customer
requirements” all too often like that? :-) Try to minimize warnings if you
-can.
-
| If you manage to produce very few warnings, or perhaps no warnings at
+can.
+
+
+If you manage to produce very few warnings, or perhaps no warnings at
all under the -Wall -Wextra -pedantic mode, then by all means brag about it in
your remarks.md file AND BE SURE TO TELL US the OS, OS version, compiler
and compiler version in which you observed this occurring (in case our OS and
compiler produces a different result: so your submission won’t be penalized for
-not meeting your claims).
-
| If your submission issues lots of warnings but is otherwise
+not meeting your claims).
+
+
+If your submission issues lots of warnings but is otherwise
marvelously obfuscated in multiple levels, don’t worry about it. Nevertheless,
be sure that the warnings do not constitute a potential “show stopper”
compiler problem. Be sure that compilers such as both gcc and clang won’t
produce a compile error and refuse to compile your code: unless for some
reason that is what you intend to happen in which case document that too in your
-remarks.md file. :-)
+
remarks.md file. :-)
+
All other things being equal, a program that must turn off fewer
warnings will be considered better, for certain values of better.
-
| To turn off a compiler warning, in your submission’s Makefile,
-try something such as:
+
+To turn off a compiler warning, in your submission’s Makefile,
+try something such as:
+
CSILENCE= -Wno-some-thing -Wno-another-thing -Wno-unknown-warning-option
-
| If you do add “-Wno-some-thing” to your Makefile,
-consider changing:
+
+
If you do add “-Wno-some-thing” to your Makefile, consider changing:
CUNKNOWN=
to:
CUNKNOWN= -Wno-unknown-warning-option
-
| Some compilers have reported this as an error, however, and if you have
-such a compiler you might want to not add it and note it in your remarks.md.
-
| If you need to define something on the compile line, use
-the CDEFINE Makefile variable. For example:
+
+Some compilers have reported this as an error, however, and if you have
+such a compiler you might want to not add it and note it in your remarks.md.
+
+
+If you need to define something on the compile line, use
+the CDEFINE Makefile variable. For example:
+
CDEFINE= -Dfoo -Dbar=baz
-
| If you need to include a file on the command line, use
-the CINCLUDE Makefile variable. For example:
+
+If you need to include a file on the command line, use
+the CINCLUDE Makefile variable. For example:
+
CINCLUDE= -include stdio.h
-
| If need to add other “magic” flags to your compile line,
-use the COTHER Makefile variable. For example:
+
+If you need to add other “magic” flags to your compile line,
+use the COTHER Makefile variable. For example:
+
COTHER= -fno-math-errno
-
NOTE: We only recommend using “magic” flags if BOTH gcc
-and clang support it.
+
+NOTE: We only recommend using “magic” flags if BOTH gcc
+and clang support it.
+
-
| We LIKE entries that use an edited variant of the
+
+We LIKE entries that use an edited variant of the
example Makefile,
renamed as Makefile of course. This makes it easier for the IOCCC Judges
to test your submission. And if your submissions wins, it makes it easier to integrate it into
-the Official IOCCC winner website.
+the
Official IOCCC winner website.
+
Doing masses of #defines to obscure the source has become ‘old’. We
tend to ‘see thru’ masses of #defines due to our pre-processor tests
that we apply. Simply abusing #defines or -Dfoo=bar won’t go as far
@@ -785,18 +942,26 @@ as a program that is more well rounded in confusion.
Many C compilers DISLIKE the following code, and so do we:
#define d define
#d foo /* <-- don't expect this to turn into #define foo */
-
| In other words, it is a compilation error.
+
+In other words, it is a compilation error.
+
When declaring local or global variables, you should declare the type:
int this_is_fine;
this_is_not; /* <-- Try to avoid implicit type declarations */
-
| We tend to like less a submission that requires either
+
+We tend to like less a submission that requires either
gcc OR clang. We prefer submissions that can compile
-under BOTH gcc AND clang.
-
| We RECOMMEND that the compiler flags you use in your
-submission’s Makefile are supported by BOTH gcc AND clang.
-
| We DISLIKE the use of obscure compiler flags, especially
+under BOTH gcc AND clang.
+
+
+We RECOMMEND that the compiler flags you use in your
+submission’s Makefile are supported by BOTH gcc AND clang.
+
+
+We DISLIKE the use of obscure compiler flags, especially
if gcc and/or clang do not support it. We suggest
-that you not use any really obscure compiler flags if you can help it.
+that you not use any really obscure compiler flags if you can help it.
+
One side effect of the above is that you cannot assume the use
of nested functions such as:
main() {
@@ -805,11 +970,13 @@ of nested functions such as:
}
| please_dont_submit_this();
}
-
| On 2012 July 20, the judges rescinded the encouragement of
+
On 2012 July 20, the judges rescinded the encouragement of
nested functions. Such constructions, while interesting and sometimes
amusing, will have to wait until they required by a C standard that are
actually implemented in BOTH gcc AND clang.
-
| We DISLIKE submissions that require the use of -fnested-functions.
+
+We DISLIKE submissions that require the use of -fnested-functions.
+
We prefer programs that do not require a fish license: crayons and
cat detector vans not withstanding.
If your submission uses functions that have a variable number of
@@ -825,43 +992,80 @@ not portable and must not be used:
using va_list as a structure or union
In particular, do not treat va_list variables as if they were a char **s.
-
| We DISLIKE the use of varargs.h. Use stdarg.h instead.
-
| We DISLIKE the use of gets(3). Use fgets(3) instead.
+
+We DISLIKE the use of varargs.h. Use stdarg.h instead.
+
+
+We DISLIKE the use of gets(3). Use fgets(3) instead.
+
On 28 January 2007, the Judges rescinded the requirement that the
# in a C preprocessor directive must be the 1st non-whitespace octet.
The exit(3) function returns void. Some broken systems have exit(3)
return int; your submission should assume that exit(3) returns a void.
-
| This guideline has a change mark at the very start of this line.
+
+This guideline has a change mark at the very start of this line.
+
Small programs are best when they are short, obscure and concise.
While such programs are not as complex as other winners, they do
serve a useful purpose: they are often the only program that people
attempt to completely understand. For this reason, we look for
programs that are compact, and are instructional.
-
| While those who are used to temperatures found on dwarf
+
+While those who are used to temperatures found on dwarf
planets
(yes Virginia, dwarf planets ARE planets!), such as
Pluto, might be able to
explain to the Walrus why our seas are boiling hot, the question of
-whether pigs have wings is likely to remain a debatable point to most.
+whether pigs have wings is likely to remain a debatable point to most.
+
One line programs should be short one line programs: say around 80 to 120
octets long. Going well beyond 140 octets is a bit too long to be called
a one-liner in our vague opinion.
We tend to DISLIKE programs that:
- are very hardware specific
-| are very OS version specific (index(3)/strchr(3) differences are OK, but sockets/streams specific code is likely not to be)
-| * dump core or have compiler warnings (it is OK only if you warn us in your remarks.md file)
-| * won’t compile or run in a Single UNIX
-Specification environment
-| * depend on a utility or application not normally found in systems that conform to the Single UNIX Specification- abuse the build file to get around the size limit
-| * obfuscate by use of ANSI trigraphs
-| * obfuscate by use of digraphs
-| * are larger than they need to be
-| * have more lines than they need to have
-| * are “blob-ier” (just a pile of unformatted C code) than they need to be
-| * are rather similar to previous winners :-(
-| * are identical to previous losers :-)
+
+are very OS version specific
+(index(3)/strchr(3) differences are OK, but sockets/streams specific code is
+likely not to be)
+
- dump core or have compiler warnings (it is OK only if
+you warn us in your
remarks.md file)
+
+won’t compile or run in a Single UNIX
+Specification
+environment
+
+depend on a utility or application not normally found
+in systems that conform to the Single UNIX
+Specification
+
- abuse the build file to get around the size limit
+
+obfuscate by use of ANSI trigraphs
+
+obfuscate by use of digraphs
+
+are larger than they need to be
+
+have more lines than they need to have
+
+are “blob-ier” (just a pile of unformatted C code)
+than they need to be
+
+are rather similar to previous
+winners :-(
+
+are identical to previous
+losers :-)
+
- that mandate the exclusive use of a specific Integrated Development Environment (IDE)
In order to encourage submission portability, we DISLIKE entries that
@@ -869,10 +1073,12 @@ fail to build unless one is using an IDE. For example, do not
mandate that one must use Microsoft Visual Studio to compile
your submission. Nevertheless some of the better IDEs have command-line
interfaces to their compilers, once one learns how to invoke a shell.
-
| The program must compile and link cleanly in a Single UNIX
+
+The program must compile and link cleanly in a Single UNIX
Specification
environment. Therefore do not assume the system has a
-windows.h include file:
+windows.h include file:
+
#include <windows.h> /* we DISLIKE this */
Unless you are cramped for space, or unless you are entering the
‘Best one liner’ category, we suggest that you format your program
@@ -889,19 +1095,25 @@ several -Ds on the compile line to help out, but it is quite anothe
many bytes of -Ds in order to try and squeeze the source under the size limit.
Your source code, post-pre-processing, should not exceed the size of
Microsoft Windows. :-)
-
| Other windows, on the other hand, might be OK: especially where “X
+
+Other windows, on the other hand, might be OK: especially where “X
marks the spot”. Yet on the third hand, windows are best when they are
-“unseen” (i.e., not dirty). :-)
+“unseen” (i.e., not dirty). :-)
+
The judges, as a group, have a history giving wide degree of latitude
to reasonable entries. And recently they have had as much longitudinal
variation as it is possible to have on Earth. :-)
-
| You should try to restrict commands used in the build file to
+
+You should try to restrict commands used in the build file to
commands found in Single UNIX Specification environments
-and systems that conform to the Single UNIX Specification.
-
| You may compile and use your own programs. If you do, try to build and execute
+and systems that conform to the Single UNIX Specification.
+
+
+You may compile and use your own programs. If you do, try to build and execute
from the current directory. This restriction is not a hard and
absolute one. The intent is to ensure that the building if your
-program is reasonably portable.
+program is reasonably portable.
+
We prefer programs that are portable across a wide variety of Unix-like
operating systems (e.g., Linux, GNU Hurd, BSD, Unix, etc.).
@@ -957,15 +1169,22 @@ they do not work as documented.
Please note that the C source below, besides lacking in obfuscation,
is NOT the smallest C source file that when compiled and run, dumps core:
main;
-| Unless you specify -fwritable-strings (see COTHER in the example
-Makefile) do not assume this sort of code will work:
+
+Unless you specify -fwritable-strings (see COTHER in the example
+Makefile)
+do not assume this sort of code will work:
+
char *T = "So many primes, so little time!";
...
T[14] = ';'; /* modifying a string requires: -fwritable-strings */
-| Initialized char arrays are OK to write over. For instance, this is OK:
+
+Initialized char arrays are OK to write over. For instance, this is OK:
+
char b[] = "Is this OK";
b[9] = 'k'; /* modifying an initialized char array is OK */
-| There are more than 1 typos in this very sentence.
+
+There are more than 1 typos in this very sentence.
+
X client entries should be as portable as possible. Submissions that
adapt to a wide collection of environments will be favored. For
example, don’t depend on a particular type or size of display.
@@ -979,22 +1198,41 @@ source program (one that actually works) to display audio/visual data.
software that are not in wide spread use.
This is the only guideline that contains the word
fizzbin.
-| However, do you know how to play fizzbin?
-You do?!? (Except on Tuesday?)
-| OK, there are actually 3 guidelines that contain the word
-fizzbin.
+
+However, do you know how to play fizzbin?
+You do?!? (Except on Tuesday?)
+
+
+OK, there are actually 3 guidelines that contain the word
+fizzbin.
+
We DISLIKE entries that use proprietary toolkits such as the M*tif,
Xv*ew, or OpenL*ok toolkits, since not everyone has them. Use an
open source toolkit that is widely and freely available instead.
NOTE: The previous guideline in this spot has been replaced by this guideline:
-| X client entries should try to not to depend on particular items in
+
+X client entries should try to not to depend on particular items in
.Xdefaults. If you must do so, be sure to note the required lines
in the your remarks.md file. They should also not depend on any
-particular window manager.
-| Try to avoid entries that play music that some people believe is copyrighted music.
-| While we recognize that UNIX is not a universal operating system, the contest does have a bias towards such systems. In an effort to expand the scope of the contest, we phrase our bias to favor the Single UNIX Specification.
-| You are well advised to submit entries that conform to the Single UNIX Specification Version 4.
-| To quote the IOCCC judges:
+particular window manager.
+
+
+Try to avoid entries that play music that some people believe is copyrighted
+music.
+
+
+While we recognize that UNIX is not a universal operating system, the contest
+does have a bias towards such systems. In an effort to expand the scope of the
+contest, we phrase our bias to favor the Single UNIX
+Specification.
+
+
+You are well advised to submit entries that conform to the Single UNIX
+Specification Version 4.
+
+
+To quote the IOCCC judges:
+
You very well might not be completely be prohibited from failing to not partly
misunderstand this particular guideline, but of course, we could not possibly
@@ -1019,17 +1257,23 @@ parliament should you have one.
Some types of programs can’t excel (anti-tm) in some areas. Your
program doesn’t have to excel in all areas, but doing well in several
areas really does help.
-| You are better off explaining what your submission does in your
+
+You are better off explaining what your submission does in your
remarks.md file section rather than leaving it obscure for the
judges as we might miss something and/or be too tired to
-notice.
-| Please avoid this specific individual guideline, if it at all possible.
-| We freely admit that interesting, creative or humorous comments in
+notice.
+
+
+Please avoid this specific individual guideline, if it at all possible.
+
+
+We freely admit that interesting, creative or humorous comments in
your remarks.md file help your chances of winning. If you had to
read so many twisted submissions, you too would enjoy a good laugh or two.
We think the readers of the contest winners do as well. We do read
your remarks.md content during the judging process, so it is worth your
-while to write remarkable remarks.md file.
+while to write remarkable remarks.md file.
+
We DISLIKE C code with trailing control-M’s (\r or \015) that results
in compilation failures. Some non-Unix/non-Linux tools such as
MS Visual C and MS Visual C++ leave trailing control-M’s on lines.
@@ -1047,10 +1291,12 @@ Instead of unescaped octets, you should use or escapes:
/* This octet requires 4 octets of source ^^^^ */
if (strlen(foo) == 36) printf("foo is 36 octets plus a final NUL\n");
else printf("This code should not print this message\n");
-| It is a very good idea to, in your remarks.md file, tell us why you
+
+It is a very good idea to, in your remarks.md file, tell us why you
think your submission is obfuscated. This is particularly true if
your submission has some very subtle obfuscations that we might
-otherwise overlook. <<– Hint!
+otherwise overlook. <<– Hint!
+
Anyone can format their code into a dense blob. A really clever
author will try format their submission using a “normal” formatting style
such that at first glance (if you squint and don’t look at the details)
@@ -1062,9 +1308,11 @@ suggest you remark on this point in your remarks.md where you talk
about why you think your submission is obfuscated. On the other hand,
if you are pushing up against the size limits, you may be forced
into creating a dense blob. Such are the trade-offs that obfuscators face!
-| We prefer code that can run on either a 64-bit or 32-bit
+
+We prefer code that can run on either a 64-bit or 32-bit
processor. However, it is UNWISE to assume it will run on an
-some Intel-like x86 architecture.
+some Intel-like x86 architecture.
+
We believe that Mark Twain’s quote:
Get your facts first, then you can distort them as you please.
@@ -1076,27 +1324,30 @@ Submitting source that uses the content of
iocccsize.c, unless you are
Anthony C Howe, might run the risk of
violating Rule 7.
-| The txzchk
-tool source is not an original work, unless you are Cody Boone
-Ferguson, in which case it is original! :-)
-Submitting source that uses the content of
-txzchk.c, unless you are
-Cody Boone Ferguson, might run the risk of
-violating Rule 7.
-| Neither the chkentry
-tool source nor the
-mkiocccentry
-tool source nor
-the fnamchk tool
+
+The txzchk tool source is not an original work,
+unless you are Cody Boone Ferguson, in
+which case it is original! :-) Submitting source that uses the content of
+txzchk.c,
+unless you are Cody Boone Ferguson, might
+run the risk of violating Rule 7.
+
+
+Neither the chkentry tool
source nor
-various others in the mkiocccentry
-repo
-are original works, unless you are Landon Curt
-Noll, in which case they are original! :-)
-Submitting source that uses the content of these tools, unless you are
-Landon Curt Noll, might run the risk of
-violating Rule 7.
-| Neither the JSON parser and
+the mkiocccentry tool
+source
+nor the fnamchk tool
+source
+nor various others in the mkiocccentry
+repo are original works, unless you
+are Landon Curt Noll, in which case
+they are original! :-) Submitting source that uses the content of these tools,
+unless you are Landon Curt Noll, might
+run the risk of violating Rule 7.
+
+
+Neither the JSON parser and
library
nor jstrencode
nor jstrdecode
@@ -1107,33 +1358,44 @@ Noll
, in which case they are original!
:-) Submitting source that uses the code of these tools or library, unless you
are Cody Boone Ferguson or Landon Curt
Noll, might run the risk of violating
-Rule 7.
-| Rule 7 does not prohibit you from writing your own
+Rule 7.
+
+
+Rule 7 does not prohibit you from writing your own
obfuscated versions of these tools, unless of course you are Landon Curt
Noll, in which case you probably won’t
win since judges are disqualified! :-)
However, if you do write your own version, you might wish to make it do something more
interesting than simply implementing the IOCCC tools’ algorithms. On the other
hand, writing an obfuscated version of a library runs the risk of violating
-Rule 1 as it is likely not a complete program.
+Rule 1 as it is likely not a complete program.
+
While programs that only run in a specific word size are OK, if you have
to pick, choose a 64-bit word size.
-| If IOCCC judges are feeling ornery we
+
+If IOCCC judges are feeling ornery we
might choose to compile your program for running on an Arduino or
a PDP-11. Heck, should we ever find an emulator of 60-bit CDC Cyber
-CPU, we might just try your submission on that emulator as well :-)
-| If your submission MUST run only on a 64-bit or 32-bit architecture,
+CPU, we might just try your submission on that emulator as well :-)
+
+
+If your submission MUST run only on a 64-bit or 32-bit architecture,
then you MUST specify the -arch on your command line
(see ARCH in the example
-Makefile). Do not assume a processor word size without specifying -arch. For example:
+Makefile). Do not assume a processor word size without specifying -arch. For example:
+
ARCH= -m64
-| Note, however, that some platforms will not necessarily support some
+
+Note, however, that some platforms will not necessarily support some
architectures. For instance, more recent versions of macOS do NOT support
-32-bit!
-| Try to be even more creative!
-| If there are limitations in your submission, you are highly encouraged
+32-bit!
+
+Try to be even more creative!
+
+If there are limitations in your submission, you are highly encouraged
to note such limitations in your remarks.md file. For example if your
-submission factors values up to a certain size, you might want to state:
+submission factors values up to a certain size, you might want to state:
+
This submission factors values up 2305567963945518424753102147331756070.
Attempting to factor larger values will produce unpredictable results.
@@ -1177,24 +1439,41 @@ and state:
program is given enough time and memory. If the value is not a proper integer,
the program might insult a fish named Eric.
-| Do not fear if you’re not 100% sure of the significance of 2305567963945518424753102147331756070 as it is not of prime importance: or is it? :-)
-| We DISLIKE the use of use ASCII tab characters in markdown files, such as in the required remarks.md file.
-| We don’t mind the use ASCII tab characters in your C code. Feel free
+
+Do not fear if you’re not 100% sure of the significance of
+2305567963945518424753102147331756070 as it is not of prime importance: or is
+it? :-)
+
+
+We DISLIKE the use of use ASCII tab characters in markdown files, such as in the required remarks.md file.
+
+
+We don’t mind the use ASCII tab characters in your C code. Feel free
to use ASCII tab characters if that suits your obfuscation needs. If is
perfectly OK to use tab characters elsewhere in your submission, just not in
markdown files as this tends complicate and annoy us when it comes time to
-rendering your markdown content.
-| If you do use ASCII tab characters in your non-markdown files, be
+rendering your markdown content.
+
+
+If you do use ASCII tab characters in your non-markdown files, be
aware that some people may use tab stop that is different than the common 8
-character tab stop.
-| PLEASE observe our IOCCC markdown guidelines
+character tab stop.
+
+
+PLEASE observe our IOCCC markdown guidelines
when forming your submission’s remarks.md file. And if your submission
contains additional markdown files, please follow those same guidelines. See
-also Rule 19.
-| We LIKE reading remarks.md files, especially if they contain
+also Rule 19.
+
+
+We LIKE reading remarks.md files, especially if they contain
useful, informative, and even humorous content about your submission. Yes, this
-is a hint. :-)
-| We RECOMMEND you put a reasonable amount effort into the content of the remarks.md file: it is a required for for a reason. :-)
+is a hint. :-)
+
+
+We RECOMMEND you put a reasonable amount effort into the content of the
+remarks.md file: it is a required for for a reason. :-)
+
ABUSING THE RULES:
@@ -1214,18 +1493,22 @@ disqualified.
RULE ABUSE CARRIES A CERTAIN LEVEL OF RISK!IOCCC rules and one that
does.
-| If you intend to abuse the IOCCC rules,
+
+If you intend to abuse the IOCCC rules,
indicate so in your remarks.md file. You MUST try to justify
why you consider your rule abuse to be allowed under the
IOCCC rules. That is, you must plead your case as to why
your submission is valid. Humor and/or creativity help plead a case.
As there is no guarantee that you will succeed, you might consider
submitting an alternate version that conforms to the
-IOCCC rules.
-| If do bypass the mkiocccentry(1) warnings about Rule
+IOCCC rules.
+
+
+If you do bypass the mkiocccentry(1) warnings about Rule
2a and/or about Rule 2b
and submit a submission anyway, you MUST try to justify why the IOCCC
-judges should not reject your submission due to a rule violation.
+judges should not reject your submission due to a rule violation.
+
Abusing the web submission procedure tends to annoy us more
than amuse us. Spend your creative energy on content of your
submission rather than on the submission process itself.
@@ -1281,7 +1564,7 @@ won an award. So it is theoretically possible that Peter Honeyman
did submit to the IOCCC in the past. In the past, Peter had denied
submitting anything to the IOCCC. Perhaps those entries were
submitted by one of his students?
-| Hopefully we are VERY CLEAR on this point! The rules now strongly state:
+
Hopefully we are VERY CLEAR on this point! The rules now strongly state:
PLEASE DO NOT put a name of an author, in an obvious way, into your
source code, remarks.md, data files, etc., the above “Peter Honeyman is
exempt” notwithstanding.
@@ -1294,11 +1577,15 @@ Because the main ‘prize’ of winning is being announced, we make all
attempts to send non-winners into oblivion. We remove all non-winning
files, and shred all related printouts. By tradition, we do not even
reveal the number of entries that we received.
-| During the judging process, a process that spans multiple sessions over
+
+During the judging process, a process that spans multiple sessions over
a few weeks, we post general updates from our Mastodon
-account.
-| Make sure you reload the feed every so often because unless you
-are mentioned you will NOT get a push notification!
+account.
+
+
+Make sure you reload the feed every so often because unless you
+are mentioned you will NOT get a push notification!
+
JUDGING ROUNDS:
@@ -1311,9 +1598,12 @@ previous round. Thus, a submission gets at least two readings.
JUDGING READINGS:
A reading consists of a number of actions:
+
+
+- reading
prog.c, the C source, reviewing the remarks.md information
+
+
-- reading
prog.c, the C source
-| * reviewing the remarks.md information
- briefly looking any any supplied data files
- passing the source thru the C pre-processor
skipping over any
#included files
@@ -1326,7 +1616,9 @@ skipping over any #included files
In later rounds, other actions are performed including performing
miscellaneous tests on the source and binary.
-
| This is the very guideline that goes, BING!
+
+This is the very guideline that goes, BING!
+
Until we reduce the stack of submissions down to about 25 submissions,
submissions are judged on an individual basis. A submission is set aside because it
does not, in our opinion, meet the standard established by the round.
@@ -1336,17 +1628,17 @@ A submission will often compete in several categories.
The actual award category list will vary depending on the types of submissions
we receive. A typical category list might be:
-- best small one line program (see above about one line programs)
+- best small one line program (see above about one line programs)
- best small program
- strangest/most creative source layout
- most useful obfuscated program
- best game that is obfuscated
- most creatively obfuscated program
-- most deceptive C code (code with deceptive comments and source code)
+- most deceptive C code (code with deceptive comments and source code)
- best X program (see OUR LIKES AND DISLIKES)
- best abuse of ISO C or ANSI C standard (see above about compilers)
- best abuse of the C preprocessor
-- worst/best abuse of the rules or some variation
+- worst/best abuse of the rules (or some variation)
- (anything else so strange that it deserves an award)
We do not limit ourselves to this list. For example, a few entries are so
@@ -1364,18 +1656,23 @@ similar, but slightly better submission. For this reason, it is sometimes
worthwhile to resubmit an improved version of a submission that failed to win in
a previous year, the next year. This assumes, of course, that the submission is
worth improving in the first place!
-
| Over the years, more than one IOCCC judge
+
+Over the years, more than one IOCCC judge
has been known to bribe another IOCCC judge into voting for a
winning entry by offering a bit of high quality chocolate, or
-other fun item.
-
| One should NOT attempt to bribe an IOCCC
+other fun item.
+
+
+One should NOT attempt to bribe an IOCCC
judge, unless you are an IOCCC judge,
because bribing an IOCCC judge by a non-judge
has been shown to NOT be effective when the person attempting
the bribe is made known to the IOCCC judges
(i.e., they are not anonymous) AND/OR the bribe is otherwise
-associated with a submission to the IOCCC.
-
| With the previous guideline in mind: anonymous gifts
+associated with a submission to the IOCCC.
+
+
+With the previous guideline in mind: anonymous gifts
for the IOCCC judges that are NOT ASSOCIATED
WITH a submission to the IOCCC may be sent to the
IOCCC judges via the
@@ -1383,14 +1680,19 @@ WITH a submission to the IOCCC may be sent
It has been shown that receiving anonymous gifts provides the
IOCCC judges with a nice
dopamine boost, and happy
-IOCCC judges help make the IOCCC better for everyone. :-)
-
| See FAQ: How may I support the IOCCC?.
+
IOCCC judges help make the
IOCCC better for everyone. :-)
+
+
+See FAQ: How may I support the IOCCC?.
+
More often than not, we select a small submission (usually one line) and a
strange/creative layout submission. We sometimes also select a
submission that abuses the IOCCC guidelines in an interesting way,
or that stretches the contest rules that while legal, it
nevertheless goes against the intent of the rules.
-
| Nevertheless, see Rule 12.
+
+Nevertheless, see Rule 12.
+
In the end, we traditionally pick one submission as ‘best’. Sometimes such
a submission simply far exceeds any of the other entries. More often, the
‘best’ is picked because it does well in a number of categories.
@@ -1400,37 +1702,63 @@ Winning source is called
prog.c. A compiled binary is called
ANNOUNCEMENT OF WINNERS:
-| The judges will toot initial announcement of who won, the name
+
+The judges will toot initial announcement of who won, the name
of their award, and a very brief description of the winning entry
-from the @IOCCC Mastodon account.
-| We recommend that you follow us on mastodon but please make sure to
+from the @IOCCC Mastodon account.
+
+
+We recommend that you follow us on mastodon but please make sure to
refresh the feed every so often (if not more often) because unless you are
-mentioned or someone boosts your post you will not get a push notification.
+mentioned or someone boosts your post you will not get a push notification.
+
How the new IOCCC winners will be announced
-| The Current status of the IOCCC will change from
-judging to closed .
-| The contest_status in the status.json file will change from judging to closed as well.
-| When the above happens, the winning entries have been selected by the IOCCC judges.
-| The IOCCC judges will begin to prepare to release the source code of the new IOCCC winners.
-| The IOCCC judges will commit the winning source to the
-IOCCC winner repo which will update the Official IOCCC website.
-| The IOCCC news will also contain an announcement of the winners.
+
+The current status of the IOCCC will change from
+judging to closed .
+
+
+The contest_status in the status.json file will change
+from judging to closed as well.
+
+
+When the above happens, the winning entries have been selected by the IOCCC
+judges.
+
+
+The IOCCC judges will begin to prepare to release the source
+code of the new IOCCC winners.
+
+
+The IOCCC judges will commit the winning source to the
+IOCCC winner repo which will update the
+Official IOCCC website.
+
+
+The IOCCC news will also contain an announcement of the winners.
+
An important update to how winners are announced
-| The IOCCC no longer uses twitter. IOCCC entries will be announced by a
+
+The IOCCC no longer uses twitter. IOCCC entries will be announced by a
git commit to the IOCCC entries repo
that, in turn, updates the Official IOCCC
-website.
-| In addition a note is posted to the IOCCC Mastodon account.
+website.
+
+
+In addition a note is posted to the IOCCC Mastodon account.
+
Back to announcement of winners
-| It is pointless to ask the IOCCC judges how many
+
+It is pointless to ask the IOCCC judges how many
submissions we receive. See How many submissions do the judges receive for a
-given IOCCC?.
+given IOCCC?.
+
Often, winning entries are published in selected magazines from around the
world. Winners have appeared in books (‘The New Hackers Dictionary’,
‘Obfuscated C and Other Mysteries’, ‘Pointers On C’, others) and on t-shirts.
@@ -1441,18 +1769,30 @@ More than one winner has been turned into a tattoo!
-
| For questions or comments about the contest, see Contacting the IOCCC.
-
| Be sure to review the IOCCC Rules and Guidelines as the
-IOCCC rules and the IOCCC guidelines may (and often do) change from year to year.
-
| You should be sure you have the current IOCCC rules and
-IOCCC guidelines prior to submitting entries.
-
| See the Official IOCCC website news for additional information.
-
| For the updates and breaking IOCCC news, you are encouraged to follow
+
+For questions or comments about the contest, see Contacting the IOCCC.
+
+
+Be sure to review the IOCCC Rules and Guidelines as the
+IOCCC rules and the IOCCC guidelines may (and often do) change from year to year.
+
+
+You should be sure you have the current IOCCC rules and
+IOCCC guidelines prior to submitting entries.
+
+
+See the Official IOCCC website news for additional information.
+
+
+For the updates and breaking IOCCC news, you are encouraged to follow
the IOCCC on Mastodon. See our
FAQ on Mastodon for more information. Please be
aware that unless you are mentioned you most likely will NOT get a
-notification so you should make sure to check the page.
-
| Check out the Official IOCCC website in general.
+notification so you should make sure to check the page.
+
+
+Check out the Official IOCCC website in general.
+
Leonid A. Broukhis
chongo (Landon Curt Noll) /\cc/\
diff --git a/next/guidelines.md b/next/guidelines.md
index bdcc8e449..5aebf1b3b 100644
--- a/next/guidelines.md
+++ b/next/guidelines.md
@@ -31,7 +31,9 @@ app from time to time to view IOCCC mastodon updates.
# 28th International Obfuscated C Code Contest Official Guidelines
+
Copyright © 2024 Leonid A. Broukhis and Landon Curt Noll.
+
All Rights Reserved. Permission for personal, education or non-profit use is
granted provided this this copyright and notice are included in its entirety
@@ -43,7 +45,9 @@ writing by [contacting the judges](../contact.html).
## IOCCC Guidelines version
-**`|`** These [IOCCC guidelines](guidelines.html) are version **28.6 2024-07-06**.
+
+These [IOCCC guidelines](guidelines.html) are version **28.7 2024-07-08**.
+
**IMPORTANT**: Be **SURE** to read the [IOCCC rules](rules.html).
@@ -52,10 +56,13 @@ writing by [contacting the judges](../contact.html).
### Change marks
-**`|`** **← Lines that start with this symbol indicate a change from the previous IOCCC**
+**← Lines that start with this symbol indicate a change from the
+previous IOCCC**.
+
Most lines (we sometimes make mistakes) that were modified since the previous
-IOCCC start with the **`|`** symbol.
+IOCCC start with a solid 4 pixel black left border (or, in the case of a code
+block or blockquote, just a vertical bar).
@@ -82,52 +89,79 @@ guidelines](guidelines.html)..
# WHAT'S NEW THIS IOCCC
-**`|`** This IOCCC runs from **2024-MMM-DD HH:MM:SS UTC** to **YYYY-MMM-DD HH:MM:SS UTC**.
-**`|`** **XXX - date/time is TBD - XXX**
+
+This IOCCC runs from **2024-MMM-DD HH:MM:SS UTC** to **YYYY-MMM-DD HH:MM:SS UTC**.
+**XXX - date/time is TBD - XXX**
+
-**`|`** The reason for the times of day are so that key IOCCC events are **calculated**
+
+The reason for the times of day are so that key IOCCC events are **calculated**
to be a **fun**ctional UTC time. :-)
+
-**`|`** Until the start of this IOCCC, the [IOCCC rules](rules.html),
+
+Until the start of this IOCCC, the [IOCCC rules](rules.html),
[IOCCC guidelines](guidelines.html) and the tools in the
[mkiocccentry repo](https://github.com/ioccc-src/mkiocccentry), should be
considered provisional **BETA** versions and **may be adjusted _AT
-ANY TIME_**.
+ANY TIME_**.
-**`|`** The submit URL should be active on or slightly before **2024-MMM-DD HH:MM:SS UTC**.
-**`|`** **XXX - date/time is TBD - XXX**
+
+The submit URL should be active on or slightly before **2024-MMM-DD HH:MM:SS UTC**.
+**XXX - date/time is TBD - XXX**
+
-**`|`** The [IOCCC rules](rules.html), [IOCCC
+
+The [IOCCC rules](rules.html), [IOCCC
guidelines](guidelines.html) will be available on the [Official IOCCC
website](https://www.ioccc.org) on or slightly before start of this IOCCC. Please check
[the IOCCC FAQ about how to submit](../faq.html#submit) to see how
to submit entries, on or after the start of this IOCCC, to be sure
you are using the correct versions of these items before using the
IOCCC submission URL.
+
-**`|`** The [Rule 2a](rules.html#rule2a) size has **increased from 4096 to 4993** bytes.
+
+The [Rule 2a](rules.html#rule2a) size has **increased from 4096 to 4993** bytes.
+
-**`|`** The [Rule 2b](rules.html#rule2b) size has **increased from 2053 to 2503** bytes.
+
+The [Rule 2b](rules.html#rule2b) size has **increased from 2053 to 2503**
+bytes.
+
-**`|`** The new default way to compile submissions: `-std=gnu17 -O3 -g3
+The new default way to compile submissions: `-std=gnu17 -O3 -g3
-Wall -Wextra -pedantic`. See below for more details about the example Makefile
for more help.
+
-**`|`** Submissions are in the form of a single xz compressed tarball.
+
+Submissions are in the form of a single xz compressed tarball.
+
-**`|`** To assist in the formation of the xz compressed tarball for submission, use the
-`mkiocccentry(1)` tool as found in the [mkiocccentry repo](https://github.com/ioccc-src/mkiocccentry).
+
+To assist in the formation of the xz compressed tarball for submission, use the
+`mkiocccentry(1)` tool as found in the [mkiocccentry
+repo](https://github.com/ioccc-src/mkiocccentry).
+
-**`|`** [Rule 17](rules.html#rule17) has been **significantly modified**
+
+[Rule 17](rules.html#rule17) has been **significantly modified**
to account for the new [mkiocccentry repo](https://github.com/ioccc-src/mkiocccentry) tools.
+
-**`|`** An [example
+
+An [example
Makefile](https://github.com/ioccc-src/mkiocccentry/blob/master/Makefile.example)
is now available from the [mkiocccentry
-repo](https://github.com/ioccc-src/mkiocccentry) and you are encouraged to use
-it.
+repo](https://github.com/ioccc-src/mkiocccentry) **and you are encouraged to use
+it**.
+
-**`|`** The IOCCC submission URL, [when the IOCCC is open](../status.html#open), is [submit.ioccc.org](https://submit.ioccc.org/).
+
+The IOCCC submission URL, [when the IOCCC is open](../status.html#open), is
+[submit.ioccc.org](https://submit.ioccc.org/).
+
@@ -178,18 +212,24 @@ entries to attempt to exploit them. We will award '**Worst abuse of the
[rules](rules.html)**' or '**Best abuse of the [rules](rules.html)**' or some
variation and then plug the hole next year.
-**`|`** When we do need to plug a hole in the [IOCCC rules](rules.html)
-or [IOCCC guidelines](guidelines.html), we will attempt to use a very
-small plug, if not smaller. Or, maybe not. :-)
+
+When we do need to plug a hole in the [IOCCC rules](rules.html) or [IOCCC
+guidelines](guidelines.html), we will attempt to use a very small plug, if not
+smaller. Or, maybe not. :-)
+
-**`|`** There may be less than 2^7+1 reasons why these [IOCCC guidelines](guidelines.html) seem obfuscated.
+
+There may be less than 2^7+1 reasons why these [IOCCC
+guidelines](guidelines.html) seem obfuscated.
+
Check out your program and be sure that it works. We sometimes make
the effort to debug a submission that has a slight problem, particularly
in or near the final round. On the other hand, we have seen some
of the best entries fall down because they didn't work.
-**`|`** We tend to look down on a [prime
+
+We tend to look down on a [prime
number](https://en.wikipedia.org/wiki/Prime_number) printer that claims that
16 is a prime number. If you do have a bug, you are better off
documenting it. Noting "_this submission sometimes prints the 4th power
@@ -197,7 +237,7 @@ of a prime by mistake_" would save the above submission. And sometimes,
a strange bug/feature can even help the submission! Of course, a correctly
working submission is best. Clever people will note that 16 might be prime
under certain conditions. Wise people, when submitting something clever
-will fully explain such cleverness in their submission's `remarks.md` file.
+will fully explain such cleverness in their submission's `remarks.md` file.
People who are considering to just use some complex mathematical
function or state machine to spell out something such as "_hello,
@@ -213,25 +253,39 @@ When programs use VTxxx/ANSI sequences, they should NOT be limited to a
specific terminal brand. Those programs that work in a standard xterm
are considered more portable.
-**`|`** [Rule 2](rules.html#rule2) (the size rule) refers to the use of the IOCCC size tool called `iocccsize(1)`.
+
+[Rule 2](rules.html#rule2) (the size rule) refers to the use of the IOCCC size
+tool called `iocccsize(1)`.
+
-**`|`** See the [mkiocccentry repo](https://github.com/ioccc-src/mkiocccentry) for the `iocccsize(1)` tool.
+
See the [mkiocccentry
+repo](https://github.com/ioccc-src/mkiocccentry) for the `iocccsize(1)` tool.
+
-**`|`** To further clarify [Rule 2](rules.html#rule2), we subdivided it into two parts, **2a** and **2b**.
+
+To further clarify [Rule 2](rules.html#rule2), we subdivided it into two parts,
+**2a** and **2b**.
+
-**`|`** The overall size limit (see [Rule 2a](rules.html#rule2a)) on `prog.c` is now **4993 bytes**.
+
+The overall size limit (see [Rule 2a](rules.html#rule2a)) on `prog.c` is now **4993 bytes**.
+
-**`|`** Your submission must satisfy BOTH the maximum size [Rule
+
+Your submission must satisfy BOTH the maximum size [Rule
2a](rules.html#rule2a) AND the IOCCC size tool [Rule 2b](rules.html#rule2b).
+
-**`|`** This IOCCC size tool imposes a 2nd limit on C code size (see [Rule 2a](rules.html#rule2a). To check your
+
+This IOCCC size tool imposes a 2nd limit on C code size (see [Rule 2a](rules.html#rule2a). To check your
code against [Rule 2](rules.html#rule2):
+
```
./iocccsize prog.c
```
-**`|`** The IOCCC size tool algorithm may be summarized as follows:
+The IOCCC size tool algorithm may be summarized as follows:
> The size tool counts most C reserved words (keyword, secondary, and selected
preprocessor keywords) as 1. The size tool counts all other octets as 1
@@ -242,20 +296,21 @@ before the end of file.
ASCII whitespace includes ASCII tab, ASCII space, ASCII newline,
ASCII formfeed, and ASCII carriage return.
-**`|`** When '`;`', '`{`' or '`}`' are within a C string, they may still not be
-**`|`** counted by the IOCCC size tool. This is a feature, not a bug!
+
+When '`;`', '`{`' or '`}`' are within a C string, they may still not be
+counted by the IOCCC size tool. This is a feature, not a bug!
In cases where the above summary and the algorithm implemented by
the IOCCC size tool source code conflict, the algorithm implemented
by the IOCCC size tool source code is preferred by the judges.
-**`|`** There are at least 2 other reasons for selecting
-**`|`** 2503 as the 2nd limit besides the fact that 2503
-**`|`** is a prime. These reasons may be searched for
-**`|`** and discovered if you are ["Curios!" about 2503](https://t5k.org/curios/page.php/2503.html). :-)
-**`|`** Moreover, 2053 was the number of the kernel disk
-**`|`** pack of one of the judge's BESM-6, and 2503 is a
-**`|`** decimal anagram of 2053.
+
+There are at least 2 other reasons for selecting 2503 as the 2nd limit besides
+the fact that 2503 is a prime. These reasons may be searched for and discovered
+if you are ["Curios!" about 2503](https://t5k.org/curios/page.php/2503.html).
+:-) Moreover, 2053 was the number of the kernel disk pack of one of the judge's
+BESM-6, and 2503 is a decimal anagram of 2053.
+
Take note that this secondary limit imposed by the IOCCC size tool
obviates some of the need to `#define` C reserved words in an effort
@@ -263,48 +318,69 @@ to get around the size limits of [Rule 2](rules.html#rule2).
Yes Virginia, **that is a hint**!
-**`|`** The [Rule 2a](rules.html#rule2a) size was changed from
+
+The [Rule 2a](rules.html#rule2a) size was changed from
4096 to 4993: a change that keeps the "2b to 2a" size ratio to a
value similar to the [2001-2012](../faq.html#size_rule2001-2012) and
[2013-2020](../faq.html#size_rule2013-2020) IOCCC eras.
+
-**`|`** [Rule 17](rules.html#rule17) (the `mkiocccentry(1)` rule) states that
+
+[Rule 17](rules.html#rule17) (the `mkiocccentry(1)` rule) states that
you **MUST** use the `mkiocccentry(1)` tool to package your submission tarball.
+
-**`|`** See the [mkiocccentry repo](https://github.com/ioccc-src/mkiocccentry)
+
+See the [mkiocccentry repo](https://github.com/ioccc-src/mkiocccentry)
for the `mkiocccentry(1)` tool.
+
-**`|`** This tool invokes a number of other tools and one, `txzchk(1)`,
+
+This tool invokes a number of other tools and one, `txzchk(1)`,
invokes another, `fnamchk(1)`.
+
-**`|`** Although the `mkiocccentry(1)` tool will verify everything for you,
+
+Although the `mkiocccentry(1)` tool will verify everything for you,
you may wish to validate each part individually. As the [rules](rules.html)
state, each of these tools have a `-h` option. However, to help simplify
matters, we give you a brief overview below.
+
-**`|`** The synopsis of the `mkiocccentry(1)` tool is:
+
+The synopsis of the `mkiocccentry(1)` tool is:
+
```
./mkiocccentry [options] work_dir prog.c \
Makefile remarks.md [file ...]
```
-**`|`** where the `work_dir` is a directory that is used to form the
+
+... where the `work_dir` is a directory that is used to form the
xz compressed tarball that `txzchk(1)` validates, `prog.c` is your submission
source code, `Makefile` is your `Makefile`, `remarks.md` is your remarks and
`[file ...]` are any additional files you wish to provide.
+
-**`|`** If the `work_dir` already exists it is an error.
+
+If the `work_dir` already exists it is an error. In the case this happens you
+will have to choose a different directory, or if it is safe to remove, you may
+do so and try again.
+
-**`|`** The `mkiocccentry(1)` tool will ask you for information about your
+
+The `mkiocccentry(1)` tool will ask you for information about your
submission as well as author details and it will run the `iocccsize(1)` tool; if
either [Rule 2a](rules.html#rule2a) or [Rule 2b](rules.html#rule2b) are broken,
it will give you the option to ignore them, if you are willing to risk this. The
tool will also do a rudimentary check on the `Makefile` and run other checks as
well. You can override warnings but doing so puts you at risk of violating
[rules](rules.html).
+
-**`|`** On the other hand, some **issues are an error** and the xz compressed
+
+On the other hand, some **issues are an error** and the xz compressed
tarball **will not be formed**. For instance, if `chkentry(1)` fails to validate
the `.auth.json` or `.info.json` [JSON](https://www.json.org/json-en.html) files
that `mkiocccentry(1)` creates, it is an error and possibly a bug that you
@@ -312,83 +388,111 @@ should report at the [mkiocccentry issues
page](https://github.com/ioccc-src/mkiocccentry/issues). **PLEASE run the
`bug_report.sh` script to help us out here!** See the [the FAQ about reporting
bugs in the mkiocccentry repo](../faq.html#mkiocccentry_bugs).
+
-
-**`|`** Assuming that `chkentry(1)` passes for both `.auth.json` and
+
+Assuming that `chkentry(1)` passes for both `.auth.json` and
`.info.json` then the tarball will be formed and then `txzchk(1)` will be
executed. In this case, there should be no problems as `mkiocccentry(1)` would
**NOT** form a tarball if there are any issues.
+
-**`|`** `txzchk(1)` performs a wide number of sanity checks on the xz
+
+`txzchk(1)` performs a wide number of sanity checks on the xz
compressed tarball and if any issues (`feathers` :-) ) are found and if you used
`mkiocccentry(1)`, then it is very possibly a bug in one of the tools and you
should report it at the [mkiocccentry issues
page](https://github.com/ioccc-src/mkiocccentry/issues). **PLEASE run the
`bug_report.sh` script to help us out here!** See [the FAQ about reporting bugs
in the mkiocccentry repo](../faq.html#mkiocccentry_bugs).
+
-**`|`** As part of its sanity checks, `txzchk(1)` will run `fnamchk(1)` on the
+
+As part of its sanity checks, `txzchk(1)` will run `fnamchk(1)` on the
_filename_ to verify that the name is valid. If this test does not pass, then it
is flagged by `txzchk(1)` but it is not an error if you wish to ignore it.
Ignoring this, however, risks violating [Rule 17](rules.html#rule17) which is a
big risk. Of course, using `mkiocccentry(1)` would prevent this from happening.
+
-**`|`** By default, `txzchk(1)` will show the contents of the tarball which is
+
+By default, `txzchk(1)` will show the contents of the tarball which is
how the `mkiocccentry(1)` shows you the tarball contents for you to review.
+
-**`|`** To help you with editing a submission, the `mkiocccentry(1)` tool has
+
+To help you with editing a submission, the `mkiocccentry(1)` tool has
some options to write _OR_ read from an answers file so you do not have to input
the information again. To write to `answers.txt` try:
+
```
./mkiocccentry -a answers.txt ...
```
-**`|`** Alternatively, if you wish to overwrite a file, you can use the `-A`
+
+Alternatively, if you wish to overwrite a file, you can use the `-A`
flag with the same option argument. Be careful that you do not accidentally
overwrite your `prog.c`!
+
-**`|`** To make use of the answers file, use the `-i answers` option like:
+
+To make use of the answers file, use the `-i answers` option like:
+
```
./mkiocccentry -i answers.txt ...
```
-**`|`** If you wish to manually run the commands you can do so. For instance, to
-check the validity of the tarball
+
+If you wish to manually run the commands you can do so. For instance, to check
+the validity of the tarball
`submit.12345678-1234-4321-abcd-1234567890ab-2.1719574527.txz ` you can do:
+
```
./txzchk submit.12345678-1234-4321-abcd-1234567890ab-2.1719574527.txz
```
-**`|`** Assuming that the tarball exists and is valid, you should see the
+
+Assuming that the tarball exists and is valid, you should see the
contents of the tarball and the words:
+
> No feathers stuck in tarball.
-**`|`** If you give the option `-q` it will not report anything unless there
+
+If you give the option `-q` it will not report anything unless there
are certain error conditions, for instance if `fnamchk(1)` reports there is a
problem with the filename; if `txzchk(1)` exits 0 then there are no problems
detected.
+
-**`|`** If you wish to run `fnamchk(1)` directly you can do so like:
+
+If you wish to run `fnamchk(1)` directly you can do so like:
+
```
./fnamchk submit.12345678-1234-4321-abcd-1234567890ab-2.1719574527.txz
```
-**`|`** Assuming everything is OK, it would show:
+
+Assuming everything is OK, it would show:
+
> `12345678-1234-4321-abcd-1234567890ab-2`
-**`|`** ... which `txzchk(1)` uses.
+
+... which `txzchk(1)` uses.
+
-**`|`** If you want to validate the `.auth.json` or `.info.json` files you
+
+If you want to validate the `.auth.json` or `.info.json` files you
should use `chkentry(1)`. `chkentry(1)` accepts more than one command line form.
If you pass a single argument, it is expected to be a directory that has both
`.auth.json` and `.info.json` in it. You can also specify a `.auth.json` and/or
`.info.json` file. An argument of `.` will skip that file. For instance:
+
```
# test entry directory test_work:
@@ -404,114 +508,150 @@ If you pass a single argument, it is expected to be a directory that has both
./chkentry .info.json .auth.json
```
-**`|`** If there is a [JSON](https://www.json.org/json-en.html) issue detected
+
+If there is a [JSON](https://www.json.org/json-en.html) issue detected
by `jparse(8)`, **then there is a [JSON](https://www.json.org/json-en.html)
error and `chkentry(1)` will report it as an _error_**. If the parsing is OK **but
there _is an issue_ in one or both of the
[JSON](https://www.json.org/json-en.html)** files **in the context of the IOCCC**,
_it will **report this as an error**_. Thus, if you were to package this manually
then you would be violating [Rule 17](rules.html#rule17).
+
-**`|`** At the risk of stating the obvious: you run **a very big risk** of having
+
+At the risk of stating the obvious: you run **a very big risk** of having
your submission rejected if you package your own tarball and there are **any
problems**. For instance, if `chkentry(1)` found a problem in your `.info.json`
file, the `mkiocccentry(1)` tool would not package it. But if you were to package
it manually, you would be violating [Rule 17](rules.html#rule17). But even if
everything checks out OK you should not expect that everything **IS** OK.
+
-**`|`** As you can see, the use of `mkiocccentry(1)` is **HIGHLY RECOMMENDED**.
+
+As you can see, the use of `mkiocccentry(1)` is **HIGHLY RECOMMENDED**.
+
-**`|`** We recommend that you use the
-[example Makefile](https://github.com/ioccc-src/mkiocccentry/blob/master/Makefile.example)
-from the [IOCCC mkiocccentry repo](https://github.com/ioccc-src/mkiocccentry).
+
+We recommend that you use the [example
+Makefile](https://github.com/ioccc-src/mkiocccentry/blob/master/Makefile.example)
+from the [IOCCC mkiocccentry repo](https://github.com/ioccc-src/mkiocccentry),
renamed as `Makefile` of course, as the starting point for your submission's
-required `Makefile`. Feel free to modify the `Makefile` to suit your obfuscated needs.
+required `Makefile`. Feel free to modify the `Makefile` to suit your obfuscated
+needs.
-**`|`** The rest of these guidelines will assume that you are using some variant of the
+
+The rest of these guidelines will assume that you are using some variant of the
[example Makefile](https://github.com/ioccc-src/mkiocccentry/blob/master/Makefile.example),
renamed as `Makefile` of course.
+
-**`|`** We suggest that you compile your submission with a commonly available
+
+We suggest that you compile your submission with a commonly available
`-std=gnu17` (ISO C 2017 with GNU extensions) C compiler.
+
-**`|`** Unless you clearly state otherwise in your `remarks.md` file AND put into your
+
+Unless you **clearly state** otherwise in your `remarks.md` file AND put into your
submission's `Makefile`, we will compile using `-std=gnu17 -O3 -g3`.
+
-**`|`** It is **OK** to require your submission to not be compiled
+
+It is **OK** to require your submission to not be compiled
using the default `-std=gnu17 -O3 -g3` settings. Simply explain why
your submission should not be compiled using `-std=gnu17 -O3 -g3` in
your `remarks.md` file and adjust your `Makefile` accordingly.
+
-**`|`** **IMPORTANT NOTE**: The use of `-std=gnu17` does **NOT** imply the use of the `gcc`
+
+**IMPORTANT NOTE**: The use of `-std=gnu17` does **NOT** imply the use of the `gcc`
compiler! We often start by compiling using the **clang** C compiler instead.
+
-**`|`** You may change the standard under which your submission is compiled
+
+You may change the standard under which your submission is compiled
by modifying the `CSTD` Makefile variable. For example, to use `c17` instead:
+
+
```
CSTD= -std=c17
```
-**`|`** For compilers, such as `clang`, that have the `-Weverything` option,
+
+For compilers, such as `clang`, that have the `-Weverything` option,
while you may wish to try it, you should look at [the FAQ about clang
-Weverything](../faq.html#weverything). We do **NOT** recommend that you put
the use of `-Weverything` into your submission's `Makefile` for the reasons
cited there. This goes even if your version does not trigger a warning as some
other version might!
+
-**`|`** You may change the level of optimization and compiler debug level
+
+You may change the level of optimization and compiler debug level
that your submission is compiled with, by modifying the `OPT` Makefile variable.
For example, to compile without optimization and debug symbols:
+
```
OPT= -O0 -g3
```
-**`|`** There is no real penalty for compiler warnings. Sometimes
+
+There is no real penalty for compiler warnings. Sometimes
compiler warnings cannot be helped: especially in the case of
obfuscated C. :-) So if you cannot easily get rid of a compiler
warning, try not fret too much.
+
-**`|`** We **LIKE** code that has a minimum of warnings, especially under the
+
+We **LIKE** code that has a minimum of warnings, especially under the
more strict ` -Wall -Wextra -pedantic` mode:
+
```
CWARN= -Wall -Wextra -pedantic
```
-**`|`** The two previous guidelines may be thought by some as being somewhat
+
+The two previous guidelines may be thought by some as being somewhat
contradictory. Isn't life, and isn't trying to satisfy "contradictory customer
requirements" all too often like that? :-) Try to minimize warnings if you
can.
+
-**`|`** If you manage to produce very few warnings, or perhaps no warnings at
+
+If you manage to produce very few warnings, or perhaps no warnings at
all under the `-Wall -Wextra -pedantic` mode, then by all means brag about it in
your `remarks.md` file **AND BE SURE TO TELL US** the OS, OS version, compiler
and compiler version in which you observed this occurring (in case our OS and
compiler produces a different result: so your submission won't be penalized for
not meeting your claims).
+
-**`|`** If your submission issues lots of warnings but is otherwise
+
+If your submission issues lots of warnings but is otherwise
marvelously obfuscated in multiple levels, don't worry about it. Nevertheless,
be sure that the warnings do not constitute a potential "**show stopper**"
compiler problem. Be sure that compilers such as both `gcc` and `clang` won't
produce a compile **error** and refuse to compile your code: unless for some
reason that is what you intend to happen in which case document that too in your
`remarks.md` file. :-)
+
All other things being equal, a program that must turn off fewer
warnings will be considered better, for certain values of better.
-
-**`|`** To turn off a compiler warning, in your submission's `Makefile`,
+
+To turn off a compiler warning, in your submission's `Makefile`,
try something such as:
+
```
CSILENCE= -Wno-some-thing -Wno-another-thing -Wno-unknown-warning-option
```
-**`|`** If you do add "`-Wno-some-thing`" to your Makefile,
-consider changing:
+
+If you do add "`-Wno-some-thing`" to your Makefile, consider changing:
```
CUNKNOWN=
@@ -523,34 +663,43 @@ to:
CUNKNOWN= -Wno-unknown-warning-option
```
-**`|`** Some compilers have reported this as an error, however, and if you have
+
+Some compilers have reported this as an error, however, and if you have
such a compiler you might want to not add it and note it in your `remarks.md`.
+
-**`|`** If you need to define something on the compile line, use
+
+If you need to define something on the compile line, use
the `CDEFINE` Makefile variable. For example:
+
```
CDEFINE= -Dfoo -Dbar=baz
```
-**`|`** If you need to include a file on the command line, use
+
+If you need to include a file on the command line, use
the `CINCLUDE` Makefile variable. For example:
+
```
CINCLUDE= -include stdio.h
```
-**`|`** If need to add other "**magic**" flags to your compile line,
+
+If you need to add other "**magic**" flags to your compile line,
use the `COTHER` Makefile variable. For example:
+
```
COTHER= -fno-math-errno
```
+
**NOTE**: **We only recommend using "_magic_" flags if _BOTH_ `gcc`
_and_ `clang`** support it.
-
+
@@ -558,11 +707,13 @@ _and_ `clang`** support it.
-**`|`** We **LIKE** entries that use an edited variant of the
+
+We **LIKE** entries that use an edited variant of the
[example Makefile](https://github.com/ioccc-src/mkiocccentry/blob/master/Makefile.example),
renamed as `Makefile` of course. This makes it easier for the [IOCCC Judges](../judges.html)
to test your submission. And if your submissions wins, it makes it easier to integrate it into
the [Official IOCCC winner website](https://www.ioccc.org/index.html).
+
Doing masses of `#define`s to obscure the source has become 'old'. We
tend to 'see thru' masses of `#define`s due to our pre-processor tests
@@ -576,7 +727,9 @@ as a program that is more well rounded in confusion.
#d foo /* <-- don't expect this to turn into #define foo */
```
-**`|`** In other words, it is a compilation error.
+
+In other words, it is a compilation error.
+
When declaring local or global variables, you should declare the type:
@@ -585,16 +738,22 @@ When declaring local or global variables, you should declare the type:
this_is_not; /* <-- Try to avoid implicit type declarations */
```
-**`|`** We tend to **like _less_** a submission that requires either
+
+We tend to **like _less_** a submission that requires either
`gcc` **OR** `clang`. **We _prefer_ submissions** that can compile
under **BOTH** `gcc` **AND** `clang`.
+
-**`|`** We **RECOMMEND** that the compiler flags you use in your
+
+We **RECOMMEND** that the compiler flags you use in your
submission's `Makefile` are supported by **BOTH** `gcc` **AND** `clang`.
+
-**`|`** We **DISLIKE** the use of obscure compiler flags, especially
+
+We **DISLIKE** the use of obscure compiler flags, especially
if `gcc` and/or `clang` do not support it. We **suggest**
that you not use any really obscure compiler flags if you can help it.
+
One side effect of the above is that you cannot assume the use
of nested functions such as:
@@ -608,12 +767,14 @@ of nested functions such as:
}
```
-**`|`** On 2012 July 20, the judges rescinded the encouragement of
+On 2012 July 20, the judges rescinded the encouragement of
nested functions. Such constructions, while interesting and sometimes
amusing, will have to wait until they required by a C standard that are
actually implemented in **BOTH** `gcc` **AND** `clang`.
-**`|`** We **DISLIKE** submissions that require the use of `-fnested-functions`.
+
+We **DISLIKE** submissions that require the use of `-fnested-functions`.
+
We prefer programs that do not require a fish license: crayons and
cat detector vans not withstanding.
@@ -632,9 +793,13 @@ not portable and _must not_ be used**:
In particular, do not treat `va_list` variables as if they were a `char **`s.
-**`|`** We **DISLIKE** the use of `varargs.h`. Use `stdarg.h` instead.
+
+We **DISLIKE** the use of `varargs.h`. Use `stdarg.h` instead.
+
-**`|`** We **DISLIKE** the use of `gets(3)`. Use `fgets(3)` instead.
+
+We **DISLIKE** the use of `gets(3)`. Use `fgets(3)` instead.
+
On 28 January 2007, the Judges rescinded the requirement that the
`#` in a C preprocessor directive must be the 1st non-whitespace octet.
@@ -642,7 +807,9 @@ On 28 January 2007, the Judges rescinded the requirement that the
The `exit(3)` function returns `void`. Some broken systems have `exit(3)`
return `int`; your submission should assume that `exit(3)` returns a `void`.
-**`|`** This _guideline_ has a change mark at the very start of this line.
+
+This _guideline_ has a change mark at the very start of this line.
+
Small programs are best when they are short, obscure and concise.
While such programs are not as complex as other winners, they do
@@ -650,12 +817,14 @@ serve a useful purpose: they are often the only program that people
attempt to completely understand. For this reason, we look for
programs that are compact, and are instructional.
-**`|`** While those who are used to temperatures found on [dwarf
+
+While those who are used to temperatures found on [dwarf
planets](https://science.nasa.gov/dwarf-planets/)
(**yes Virginia, dwarf planets _ARE_ planets!**), such as
[Pluto](https://science.nasa.gov/dwarf-planets/pluto/), might be able to
explain to the Walrus why our seas are boiling hot, the question of
whether pigs have wings is likely to remain a debatable point to most.
+
One line programs should be short one line programs: say around 80 to 120
octets long. Going well beyond 140 octets is a bit too long to be called
@@ -664,19 +833,28 @@ a one-liner in our vague opinion.
We tend to **DISLIKE** programs that:
* are very hardware specific
-* **`|`** are very OS version specific (`index(3)`/`strchr(3)` differences are OK, but sockets/streams specific code is likely not to be)
-**`|`** * dump core or have compiler warnings (it is OK only if you warn us in your `remarks.md` file)
-**`|`** * won't compile or run in a [Single UNIX
-Specification](https://en.wikipedia.org/wiki/Single_UNIX_Specification) environment
-**`|`** * depend on a utility or application not normally found in systems that conform to the [Single UNIX Specification](https://en.wikipedia.org/wiki/Single_UNIX_Specification)
+*
are very OS version specific
+(`index(3)`/`strchr(3)` differences are OK, but sockets/streams specific code is
+likely not to be)
+* dump core or have compiler warnings (it is OK only if
+you warn us in your `remarks.md` file)
+*
won't compile or run in a [Single UNIX
+Specification](https://en.wikipedia.org/wiki/Single_UNIX_Specification)
+environment
+*
depend on a utility or application not normally found
+in systems that conform to the [Single UNIX
+Specification](https://en.wikipedia.org/wiki/Single_UNIX_Specification)
* abuse the build file to get around the size limit
-**`|`** * obfuscate by use of ANSI trigraphs
-**`|`** * obfuscate by use of digraphs
-**`|`** * are larger than they need to be
-**`|`** * have more lines than they need to have
-**`|`** * are "blob-ier" (just a pile of unformatted C code) than they need to be
-**`|`** * are rather similar to **[previous winners](../years.html)** :-(
-**`|`** * are **identical** to **previous losers** :-)
+*
obfuscate by use of ANSI trigraphs
+*
obfuscate by use of digraphs
+*
are larger than they need to be
+*
have more lines than they need to have
+*
are "blob-ier" (just a pile of unformatted C code)
+than they need to be
+*
are rather similar to **[previous
+winners](../years.html)** :-(
+*
are **identical** to **[previous
+losers](https://en.wikipedia.org/wiki/Null_device)** :-)
* that mandate the exclusive use of a specific Integrated Development Environment (IDE)
In order to encourage submission portability, we **DISLIKE** entries that
@@ -685,10 +863,12 @@ mandate that one must use Microsoft Visual Studio to compile
your submission. Nevertheless some of the better IDEs have command-line
interfaces to their compilers, once one learns how to invoke a shell.
-**`|`** The program must compile and link cleanly in a [Single UNIX
+
+The program must compile and link cleanly in a [Single UNIX
Specification](https://en.wikipedia.org/wiki/Single_UNIX_Specification)
environment. Therefore do not assume the system has a
[windows.h](https://en.wikipedia.org/wiki/Windows.h) include file:
+
```
@@ -714,22 +894,28 @@ many bytes of `-D`s in order to try and squeeze the source under the size limit.
Your source code, post-pre-processing, should not exceed the size of
[Microsoft Windows](https://en.wikipedia.org/wiki/Microsoft_Windows). :-)
-**`|`** Other windows, on the other hand, might be OK: especially where "**X
+
+Other windows, on the other hand, might be OK: especially where "**X
marks the spot**". Yet on the third hand, windows are best when they are
"unseen" (i.e., not dirty). :-)
+
The judges, as a group, have a history giving wide degree of latitude
to reasonable entries. And recently they have had as much longitudinal
variation as it is possible to have on [Earth](https://science.nasa.gov/earth/). :-)
-**`|`** You should try to restrict commands used in the build file to
+
+You should try to restrict commands used in the build file to
commands found in [Single UNIX Specification](https://en.wikipedia.org/wiki/Single_UNIX_Specification) environments
and systems that conform to the [Single UNIX Specification](https://en.wikipedia.org/wiki/Single_UNIX_Specification).
+
-**`|`** You may compile and use your own programs. If you do, try to build and execute
+
+You may compile and use your own programs. If you do, try to build and execute
from the current directory. This restriction is not a hard and
absolute one. The intent is to ensure that the building if your
program is reasonably portable.
+
We prefer programs that are portable across a wide variety of Unix-like
operating systems (e.g., Linux, GNU Hurd, BSD, Unix, etc.).
@@ -807,8 +993,11 @@ is NOT the smallest C source file that when compiled and run, dumps core:
main;
```
-**`|`** Unless you specify `-fwritable-strings` (see `COTHER` in the [example
-Makefile](https://github.com/ioccc-src/mkiocccentry/blob/master/Makefile.example)) do not assume this sort of code will work:
+
+Unless you specify `-fwritable-strings` (see `COTHER` in the [example
+Makefile](https://github.com/ioccc-src/mkiocccentry/blob/master/Makefile.example))
+do not assume this sort of code will work:
+
```
char *T = "So many primes, so little time!";
@@ -816,14 +1005,18 @@ Makefile](https://github.com/ioccc-src/mkiocccentry/blob/master/Makefile.example
T[14] = ';'; /* modifying a string requires: -fwritable-strings */
```
-**`|`** Initialized char arrays are OK to write over. For instance, this is OK:
+
+Initialized char arrays are OK to write over. For instance, this is OK:
+
```
char b[] = "Is this OK";
b[9] = 'k'; /* modifying an initialized char array is OK */
```
-**`|`** There are more than 1 typos in this very sentence.
+
+There are more than 1 typos in this very sentence.
+
X client entries should be as portable as possible. Submissions that
adapt to a wide collection of environments will be favored. For
@@ -841,11 +1034,15 @@ software that are not in wide spread use.
This is the only _guideline_ that contains the word
[fizzbin](https://en.wikipedia.org/wiki/List_of_games_in_Star_Trek#Fizzbin).
-**`|`** However, do you know how to play [fizzbin](https://en.wikipedia.org/wiki/List_of_games_in_Star_Trek#Fizzbin)?
+
+However, do you know how to play [fizzbin](https://en.wikipedia.org/wiki/List_of_games_in_Star_Trek#Fizzbin)?
You do?!? (Except on Tuesday?)
+
-**`|`** OK, there are actually 3 _guidelines_ that contain the word
+
+OK, there are actually 3 _guidelines_ that contain the word
[fizzbin](https://en.wikipedia.org/wiki/List_of_games_in_Star_Trek#Fizzbin).
+
We **DISLIKE** entries that use proprietary toolkits such as the `M*tif`,
`Xv*ew`, or `OpenL*ok` toolkits, since not everyone has them. Use an
@@ -853,18 +1050,33 @@ open source toolkit that is widely and freely available instead.
**NOTE**: The previous _guideline_ in this spot has been replaced by this _guideline_:
-**`|`** X client entries should try to not to depend on particular items in
+
+X client entries should try to not to depend on particular items in
`.Xdefaults`. If you must do so, be sure to note the required lines
in the your `remarks.md` file. They should also not depend on any
particular window manager.
+
-**`|`** Try to avoid entries that play music that some people believe is copyrighted music.
+
+Try to avoid entries that play music that some people believe is copyrighted
+music.
+
-**`|`** While we recognize that UNIX is not a universal operating system, the contest does have a bias towards such systems. In an effort to expand the scope of the contest, we phrase our bias to favor the [Single UNIX Specification](https://en.wikipedia.org/wiki/Single_UNIX_Specification).
+
+While we recognize that UNIX is not a universal operating system, the contest
+does have a bias towards such systems. In an effort to expand the scope of the
+contest, we phrase our bias to favor the [Single UNIX
+Specification](https://en.wikipedia.org/wiki/Single_UNIX_Specification).
+
-**`|`** You are **well advised** to submit entries that conform to the [Single UNIX Specification Version 4](https://unix.org/version4/overview.html).
+
+You are **well advised** to submit entries that conform to the [Single UNIX
+Specification Version 4](https://unix.org/version4/overview.html).
+
-**`|`** To quote the [IOCCC judges](../judges.html):
+
+To quote the [IOCCC judges](../judges.html):
+
> You very well might not be completely be prohibited from failing to not partly
misunderstand this particular _guideline_, but of course, we could not possibly
@@ -891,19 +1103,25 @@ Some types of programs can't excel (anti-tm) in some areas. Your
program doesn't have to excel in all areas, but doing well in several
areas really does help.
-**`|`** You are better off explaining what your submission does in your
+
+You are better off explaining what your submission does in your
`remarks.md` file section rather than leaving it obscure for the
[judges](../judges.html) as we might miss something and/or be too tired to
notice.
+
-**`|`** Please avoid this specific individual _guideline_, if it at all possible.
+
+Please avoid this specific individual _guideline_, if it at all possible.
+
-**`|`** We freely admit that interesting, creative or humorous comments in
+
+We freely admit that interesting, creative or humorous comments in
your `remarks.md` file help your chances of winning. If you had to
read so many twisted submissions, you too would enjoy a good laugh or two.
We think the readers of the contest winners do as well. We do read
your `remarks.md` content during the judging process, so it is worth your
while to write remarkable `remarks.md` file.
+
We **DISLIKE** C code with trailing control-M's (`\r` or `\015`) that results
in compilation failures. Some non-Unix/non-Linux tools such as
@@ -928,10 +1146,12 @@ Instead of unescaped octets, you should use \octal or \hex escapes:
else printf("This code should not print this message\n");
```
-**`|`** It is a very good idea to, in your `remarks.md` file, tell us why you
+
+It is a very good idea to, in your `remarks.md` file, tell us why you
think your submission is obfuscated. This is particularly true if
your submission has some very subtle obfuscations that we might
otherwise overlook. **<<-- Hint!**
+
Anyone can format their code into a dense blob. A really clever
author will try format their submission using a "normal" formatting style
@@ -946,9 +1166,11 @@ about why you think your submission is obfuscated. On the other hand,
if you are pushing up against the size limits, you may be forced
into creating a dense blob. Such are the trade-offs that obfuscators face!
-**`|`** We prefer code that can run on either a 64-bit or 32-bit
+
+We prefer code that can run on either a 64-bit or 32-bit
processor. However, it is **UNWISE **to assume it will run on an
some Intel-like x86 architecture.
+
We believe that Mark Twain's quote:
@@ -963,29 +1185,31 @@ Submitting source that uses the content of
[Anthony C Howe](../authors.html#Anthony_C_Howe), might run the risk of
violating [Rule 7](rules.html#rule7).
-**`|`** The `txzchk`
-tool source is not an original work, unless you are [Cody Boone
-Ferguson](../authors.html#Cody_Boone_Ferguson), in which case it is original! :-)
-Submitting source that uses the content of
-[txzchk.c](https://github.com/ioccc-src/mkiocccentry/blob/master/txzchk.c), unless you are
-[Cody Boone Ferguson](../authors.html#Cody_Boone_Ferguson), might run the risk of
-violating [Rule 7](rules.html#rule7).
+
The `txzchk` tool source is not an original work,
+unless you are [Cody Boone Ferguson](../authors.html#Cody_Boone_Ferguson), in
+which case it is original! :-) Submitting source that uses the content of
+[txzchk.c](https://github.com/ioccc-src/mkiocccentry/blob/master/txzchk.c),
+unless you are [Cody Boone Ferguson](../authors.html#Cody_Boone_Ferguson), might
+run the risk of violating [Rule 7](rules.html#rule7).
-**`|`** Neither the [chkentry
-tool source](https://github.com/ioccc-src/mkiocccentry/blob/master/chkentry.c) nor the
-[mkiocccentry
-tool source](https://github.com/ioccc-src/mkiocccentry/blob/master/mkiocccentry.c) nor
-the [fnamchk tool
-source](https://github.com/ioccc-src/mkiocccentry/blob/master/test_ioccc/fnamchk.c) nor
-various others in the [mkiocccentry
-repo](https://github.com/ioccc-src/mkiocccentry)
-are original works, unless you are [Landon Curt
-Noll](http://www.isthe.com/chongo/index.html), in which case they are original! :-)
-Submitting source that uses the content of these tools, unless you are
-[Landon Curt Noll](http://www.isthe.com/chongo/index.html), might run the risk of
-violating [Rule 7](rules.html#rule7).
+
+Neither the [chkentry tool
+source](https://github.com/ioccc-src/mkiocccentry/blob/master/chkentry.c) nor
+the [mkiocccentry tool
+source](https://github.com/ioccc-src/mkiocccentry/blob/master/mkiocccentry.c)
+nor the [fnamchk tool
+source](https://github.com/ioccc-src/mkiocccentry/blob/master/test_ioccc/fnamchk.c)
+nor various others in the [mkiocccentry
+repo](https://github.com/ioccc-src/mkiocccentry) are original works, unless you
+are [Landon Curt Noll](http://www.isthe.com/chongo/index.html), in which case
+they are original! :-) Submitting source that uses the content of these tools,
+unless you are [Landon Curt Noll](http://www.isthe.com/chongo/index.html), might
+run the risk of violating [Rule 7](rules.html#rule7).
+
-**`|`** Neither the [JSON parser and
+
+
+Neither the [JSON parser and
library](https://github.com/ioccc-src/mkiocccentry/blob/master/jparse/README.md)
nor [jstrencode](https://github.com/ioccc-src/mkiocccentry/blob/master/jparse/jstrencode.c)
nor [jstrdecode](https://github.com/ioccc-src/mkiocccentry/blob/master/jparse/jstrdecode.c)
@@ -996,43 +1220,52 @@ Noll](http://www.isthe.com/chongo/index.html), in which case they are original!
:-) Submitting source that uses the code of these tools or library, unless you
are [Cody Boone Ferguson](../authors.html#Cody_Boone_Ferguson) or [Landon Curt
Noll](http://www.isthe.com/chongo/index.html), might run the risk of violating
-[Rule 7](rules.html#rule7).
+[Rule 7](rules.html#rule7).
-**`|`** [Rule 7](rules.html#rule7) does not prohibit you from writing your own
+
+[Rule 7](rules.html#rule7) does not prohibit you from writing your own
obfuscated versions of these tools, unless of course you are [Landon Curt
Noll](http://www.isthe.com/chongo/index.html), in which case you _probably_ won't
win since judges are disqualified! :-)
However, _**if you do** write your own version, **you might wish** to make it do something more
interesting_ than simply implementing the [IOCCC](../index.html) tools' algorithms. On the other
hand, writing an obfuscated version of a library runs the risk of violating
-[Rule 1](rules.html#rule1) as it is likely not a complete program.
+[Rule 1](rules.html#rule1) as it is likely not a complete program.
While programs that only run in a specific word size are OK, if you have
to pick, choose a 64-bit word size.
-**`|`** If [IOCCC judges](../judges.html) are feeling ornery we
+
+If [IOCCC judges](../judges.html) are feeling ornery we
might choose to compile your program for running on an Arduino or
a PDP-11. Heck, should we ever find an emulator of 60-bit CDC Cyber
CPU, we might just try your submission on that emulator as well :-)
+
-**`|`** If your submission **MUST** run only on a 64-bit or 32-bit architecture,
+
+If your submission **MUST** run only on a 64-bit or 32-bit architecture,
then you **MUST** specify the `-arch` on your command line
(see `ARCH` in the [example
Makefile](https://github.com/ioccc-src/mkiocccentry/blob/master/Makefile.example)). Do not assume a processor word size without specifying `-arch`. For example:
+
```
ARCH= -m64
```
-**`|`** Note, however, that some platforms will not necessarily support some
+
+Note, however, that some platforms will not necessarily support some
architectures. For instance, more recent versions of `macOS` do **NOT** support
32-bit!
+
-**`|`** Try to be even more creative!
+Try to be even more creative!
-**`|`** If there are limitations in your submission, you are highly encouraged
+
+If there are limitations in your submission, you are highly encouraged
to note such limitations in your `remarks.md` file. For example if your
submission factors values up to a certain size, you might want to state:
+
> This submission factors values up `2305567963945518424753102147331756070`.
Attempting to factor larger values will produce unpredictable results.
@@ -1076,32 +1309,47 @@ and state:
program is given enough time and memory. If the value is not a proper integer,
the program might insult a fish named Eric.
-**`|`** Do not fear if you're not 100% sure of the significance of `2305567963945518424753102147331756070` as it is not of prime importance: or is it? :-)
+
+Do not fear if you're not 100% sure of the significance of
+`2305567963945518424753102147331756070` as it is not of prime importance: or is
+it? :-)
+
-**`|`** We **DISLIKE** the use of use ASCII tab characters in markdown files, such as in the required `remarks.md` file.
+
+We **DISLIKE** the use of use ASCII tab characters in markdown files, such as in the required `remarks.md` file.
+
-**`|`** We don't mind the use ASCII tab characters in your C code. Feel free
+
+We don't mind the use ASCII tab characters in your C code. Feel free
to use ASCII tab characters if that suits your obfuscation needs. If is
perfectly **OK** to use tab characters elsewhere in your submission, just not in
markdown files as this tends complicate and annoy us when it comes time to
rendering your markdown content.
+
-**`|`** If you do use ASCII tab characters in your non-markdown files, be
+
+If you do use ASCII tab characters in your non-markdown files, be
aware that some people may use tab stop that is different than the common 8
character tab stop.
+
-**`|`** **PLEASE** observe our [IOCCC markdown guidelines](../markdown.html)
+
+**PLEASE** observe our [IOCCC markdown guidelines](../markdown.html)
when forming your submission's `remarks.md` file. And if your submission
contains additional markdown files, please follow those same guidelines. See
also [Rule 19](rules.html#rule19).
+
-**`|`** We **LIKE** reading `remarks.md` files, especially if they contain
+
+We **LIKE** reading `remarks.md` files, especially if they contain
useful, informative, and even humorous content about your submission. Yes, this
is a **hint**. :-)
+
-**`|`** We **RECOMMEND** you put a reasonable amount effort into the content of the `remarks.md` file: it is a required for for a reason. :-)
-
-
+
+We **RECOMMEND** you put a reasonable amount effort into the content of the
+`remarks.md` file: it is a required for for a reason. :-)
+
@@ -1127,7 +1375,8 @@ have a submission that might otherwise be interesting, you might want to
submit two versions; one that does not abuse the [IOCCC rules](rules.html) and one that
does.
-**`|`** If you intend to abuse the [IOCCC rules](rules.html),
+
+If you intend to abuse the [IOCCC rules](rules.html),
indicate so in your `remarks.md` file. You **MUST** try to justify
why you consider your rule abuse to be allowed under the
[IOCCC rules](rules.html). That is, you must plead your case as to why
@@ -1135,11 +1384,14 @@ your submission is valid. Humor and/or creativity help plead a case.
As there is no guarantee that you will succeed, you might consider
submitting an alternate version that conforms to the
[IOCCC rules](rules.html).
+
-**`|`** If do bypass the `mkiocccentry(1)` warnings about [Rule
+
+If you do bypass the `mkiocccentry(1)` warnings about [Rule
2a](rules.html#rule2a) and/or about [Rule 2b](rules.html#rule2b)
and submit a submission anyway, you **MUST** try to justify why the IOCCC
judges should not reject your submission due to a rule violation.
+
Abusing the web submission procedure tends to annoy us more
than amuse us. Spend your creative energy on content of your
@@ -1208,7 +1460,7 @@ did submit to the IOCCC in the past. In the past, Peter had denied
submitting anything to the IOCCC. Perhaps those entries were
submitted by one of his students?
-**`|`** Hopefully we are **VERY CLEAR** on this point! The rules now strongly state:
+Hopefully we are **VERY CLEAR** on this point! The rules now strongly state:
**PLEASE _DO NOT_ put a name of an author**, in an obvious way, into your
source code, `remarks.md`, data files, etc., the above "**Peter Honeyman is
exempt**" notwithstanding.
@@ -1225,12 +1477,16 @@ attempts to send non-winners into oblivion. We remove all non-winning
files, and shred all related printouts. By tradition, we do not even
reveal the number of entries that we received.
-**`|`** During the judging process, a process that spans multiple sessions over
+
+During the judging process, a process that spans multiple sessions over
a few weeks, we post general updates from our [Mastodon
account](https://fosstodon.org/@ioccc).
+
-**`|`** **Make sure you reload the feed** every so often **because unless you
+
+**Make sure you reload the feed** every so often **because unless you
are mentioned you will NOT get a push notification!**
+
## JUDGING ROUNDS:
@@ -1248,8 +1504,9 @@ previous round. Thus, a submission gets at least two readings.
A reading consists of a number of actions:
-* reading `prog.c`, the C source
-**`|`** * reviewing the `remarks.md` information
+
+* reading `prog.c`, the C source, reviewing the `remarks.md` information
+
* briefly looking any any supplied data files
* passing the source thru the C pre-processor
skipping over any `#include`d files
@@ -1263,7 +1520,9 @@ A reading consists of a number of actions:
In later rounds, other actions are performed including performing
miscellaneous tests on the source and binary.
-**`|`** This is the very **guideline** that goes, **BING!**
+
+This is the very **guideline** that goes, **BING!**
+
Until we reduce the stack of submissions down to about 25 submissions,
submissions are judged on an individual basis. A submission is set aside because it
@@ -1275,17 +1534,17 @@ A submission will often compete in several categories.
The actual award category list will vary depending on the types of submissions
we receive. A typical category list might be:
-* **best small one line program (see above about one line programs)**
+* **best small one line program** (see above about one line programs)
* **best small program**
* **strangest/most creative source layout**
* **most useful obfuscated program**
* **best game that is obfuscated**
* **most creatively obfuscated program**
-* **most deceptive C code (code with deceptive comments and source code)**
+* **most deceptive C code** (code with deceptive comments and source code)
* **best X program** (see [OUR LIKES AND DISLIKES](#likes))
* **best abuse of ISO C or ANSI C standard** (see above about compilers)
* **best abuse of the C preprocessor**
-* **worst/best abuse of the rules** or some variation
+* **worst/best abuse of the rules** (or some variation)
* (anything else so strange that it deserves an award)
We do not limit ourselves to this list. For example, a few entries are so
@@ -1307,20 +1566,25 @@ worthwhile to resubmit an improved version of a submission that failed to win in
a previous year, the next year. This assumes, of course, that the submission is
worth improving in the first place!
-**`|`** Over the years, more than one [IOCCC judge](../judges.html)
+
+Over the years, more than one [IOCCC judge](../judges.html)
has been known to **bribe** another IOCCC [judge](../judges.html) into voting for a
winning entry by offering a bit of high quality chocolate, or
other fun item.
+
-**`|`** One **should NOT** attempt to **bribe** an [IOCCC
+
+One **should NOT** attempt to **bribe** an [IOCCC
judge](../judges.html), **unless you are an [IOCCC judge](../judges.html)**,
because **bribing** an [IOCCC judge](../judges.html) by a non-judge
has been shown to **NOT** be effective when the **person _attempting_
the _bribe_ is made known** to the [IOCCC judges](../judges.html)
(i.e., they are not anonymous) AND/OR the **bribe** is otherwise
associated with a submission to the [IOCCC](../index.html).
+
-**`|`** With the previous guideline in mind: **anonymous** gifts
+
+With the previous guideline in mind: **anonymous** gifts
for the [IOCCC judges](../judges.html) that are **NOT ASSOCIATED
WITH** a submission to the [IOCCC](../index.html) may be sent to the
[IOCCC judges](../judges.html) via the
@@ -1329,8 +1593,11 @@ It has been shown that receiving **anonymous** gifts provides the
[IOCCC judges](../judges.html) with a nice
[dopamine](https://en.wikipedia.org/wiki/Dopamine) boost, and happy
[IOCCC judges](../judges.html) help make the [IOCCC](../index.html) better for everyone. :-)
+
-**`|`** See [FAQ: How may I support the IOCCC?](../faq.html#support).
+
+See [FAQ: How may I support the IOCCC?](../faq.html#support).
+
More often than not, we select a small submission (usually one line) and a
strange/creative layout submission. We sometimes also select a
@@ -1338,7 +1605,9 @@ submission that abuses the [IOCCC guidelines](guidelines.html) in an interesting
or that stretches the contest [rules](rules.html) that while legal, it
nevertheless goes against the **intent** of the [rules](rules.html).
-**`|`** Nevertheless, see [Rule 12](rules.html#rule12).
+
+Nevertheless, see [Rule 12](rules.html#rule12).
+
In the end, we traditionally pick one submission as '**best**'. Sometimes such
a submission simply far exceeds any of the other entries. More often, the
@@ -1353,53 +1622,79 @@ Winning source is called `prog.c`. A compiled binary is called `prog`.
# ANNOUNCEMENT OF WINNERS:
-**`|`** The [judges](../judges.html) will toot initial announcement of who won, the name
+
+The [judges](../judges.html) will toot initial announcement of who won, the name
of their award, and a very brief description of the winning entry
from the [@IOCCC Mastodon account](https://fosstodon.org/@ioccc).
+
-**`|`** We recommend that you follow us on mastodon but **please make sure to
+
+We recommend that you follow us on mastodon but **please make sure to
refresh the feed** every so often (if not more often) because unless you are
mentioned or someone boosts your post you will not get a push notification.
+
## How the new IOCCC winners will be announced
-**`|`** The [Current status of the IOCCC](../status.html) will change from
+
+The [current status of the IOCCC](../status.html) will change from
**[judging](../status.html#judging)** to **[closed](../status.html#closed)** .
+
-**`|`** The **contest_status** in the [status.json](../status.json) file will change from **judging** to **closed** as well.
+
+The **contest_status** in the [status.json](../status.json) file will change
+from **judging** to **closed** as well.
+
-**`|`** When the above happens, the winning entries have been selected by the [IOCCC judges](../judges.html).
+
+When the above happens, the winning entries have been selected by the [IOCCC
+judges](../judges.html).
+
-**`|`** The [IOCCC judges](../judges.html) will begin to prepare to release the source code of the new IOCCC winners.
+
+The [IOCCC judges](../judges.html) will begin to prepare to release the source
+code of the new IOCCC winners.
+
-**`|`** The [IOCCC judges](../judges.html) will commit the winning source to the
-[IOCCC winner repo](https://github.com/ioccc-src/winner) which will update the [Official IOCCC website](https://www.ioccc.org/index.html).
+
+The [IOCCC judges](../judges.html) will commit the winning source to the
+[IOCCC winner repo](https://github.com/ioccc-src/winner) which will update the
+[Official IOCCC website](https://www.ioccc.org/index.html).
+
-**`|`** The [IOCCC news](../news.html) will also contain an announcement of the winners.
+
+The [IOCCC news](../news.html) will also contain an announcement of the winners.
+
## An important update to how winners are announced
-**`|`** The IOCCC no longer uses twitter. IOCCC entries will be announced by a
+
+The IOCCC no longer uses twitter. IOCCC entries will be announced by a
`git` commit to the [IOCCC entries repo](https://github.com/ioccc-src/winner)
that, in turn, updates the [Official IOCCC
website](https://www.ioccc.org/index.html).
+
-**`|`** In addition a note is posted to the [IOCCC Mastodon account](https://fosstodon.org/@ioccc).
+
+In addition a note is posted to the [IOCCC Mastodon account](https://fosstodon.org/@ioccc).
+
## Back to announcement of winners
-**`|`** It is pointless to ask the [IOCCC judges](../judges.html) how many
+
+It is pointless to ask the [IOCCC judges](../judges.html) how many
submissions we receive. See [How many submissions do the judges receive for a
given IOCCC?](../faq.html#how_many).
+
Often, winning entries are published in selected magazines from around the
world. Winners have appeared in books ('`The New Hackers Dictionary`',
@@ -1415,23 +1710,35 @@ Last, but not least, [winners](../authors.html) receive international fame and f
+For questions or comments about the contest, see [Contacting the IOCCC](../contact.html).
+
-**`|`** Be sure to review the [IOCCC Rules and Guidelines](index.html) as the
+
+Be sure to review the [IOCCC Rules and Guidelines](index.html) as the
[IOCCC rules](rules.html) and the [IOCCC guidelines](guidelines.html) may (and often do) change from year to year.
+
-**`|`** You should be sure you have the current [IOCCC rules](rules.html) and
+
+You should be sure you have the current [IOCCC rules](rules.html) and
[IOCCC guidelines](guidelines.html) prior to submitting entries.
+
-**`|`** See the [Official IOCCC website news](../news.html) for additional information.
+
+See the [Official IOCCC website news](../news.html) for additional information.
+
-**`|`** For the updates and breaking [IOCCC news](../news.html), you are encouraged to follow
+
+For the updates and breaking [IOCCC news](../news.html), you are encouraged to follow
the [IOCCC on Mastodon](https://fosstodon.org/@ioccc). See our
[FAQ on Mastodon](../faq.html#try_mastodon) for more information. **Please be
aware** that unless you are mentioned you most likely will **NOT** get a
notification so you should make sure to check the page.
+
-**`|`** Check out the [Official IOCCC website](https://www.ioccc.org/index.html) in general.
+
+Check out the [Official IOCCC website](https://www.ioccc.org/index.html) in general.
+
Leonid A. Broukhis
chongo (Landon Curt Noll) /\\cc/\\
diff --git a/next/rules.html b/next/rules.html
index b7f62c795..29897b7e3 100644
--- a/next/rules.html
+++ b/next/rules.html
@@ -405,7 +405,9 @@ app from time to time to view IOCCC mastodon updates.
28th International Obfuscated C Code Contest Official Rules
-| Copyright © 2024 Leonid A. Broukhis and Landon Curt Noll.
+
+Copyright © 2024 Leonid A. Broukhis and Landon Curt Noll.
+
All Rights Reserved. Permission for personal, education or non-profit use is
granted provided this this copyright and notice are included in its entirety
and remains unaltered. All other uses must receive prior permission in
@@ -413,14 +415,19 @@ writing by contacting the judges.
IOCCC Rules version
-| These IOCCC rules are version 28.4 2024-07-02.
+
+These IOCCC rules are version 28.5 2024-07-08.
+
IMPORTANT: Be sure to read the IOCCC guidelines.
Change marks
-| ← Lines that start with this symbol indicate a change from the previous IOCCC
+
+← Lines that start with this symbol indicate a change from the previous IOCCC
+
Most lines (we sometimes make mistakes) that were modified since the previous
-IOCCC start with the | symbol.
+IOCCC start with a solid 4 pixel black left border (or, in the case of a code
+block or blockquote, just a vertical bar).
Obfuscate defined:
@@ -446,19 +453,25 @@ IOCCC start with the | symbol.
Important IOCCC dates
-| This IOCCC runs from 2024-MMM-DD HH:MM:SS UTC to 202x-MMM-DD HH:MM:SS UTC.
-| XXX - date/time is TBD - XXX
-| Until the start of this IOCCC, these IOCCC rules,
+
+This IOCCC runs from 2024-MMM-DD HH:MM:SS UTC to 202x-MMM-DD HH:MM:SS UTC.
+XXX - date/time is TBD - XXX
+
+
+Until the start of this IOCCC, these IOCCC rules,
IOCCC guidelines and the mkiocccentry
toolkit should be considered
-provisional BETA versions and may be adjusted AT ANY TIME.
+provisional BETA versions and may be adjusted AT ANY TIME.
+
When the IOCCC is open, the submission URL is:
https://submit.ioccc.org; at all other
times that link is likely to be unresponsive.
Please check the How to enter FAQ
for important information on how to submit to the IOCCC.
-| The submit URL should be active on or slightly before 2024-MMM-DD HH:MM:SS UTC.
-| XXX - date/time is TBD - XXX
+
+The submit URL should be active on or slightly before 2024-MMM-DD HH:MM:SS UTC.
+XXX - date/time is TBD - XXX
+
Please wait to submit your entries until after that time.
The official IOCCC rules and IOCCC guidelines will be
available on the official IOCCC website on or slightly before
@@ -486,44 +499,66 @@ submission URL.
Rule 2a
-| The size of your program source should not exceed 4993 bytes.
-| If you use the most recently released official IOCCC submission
+
+The size of your program source should not exceed 4993 bytes.
+
+
+If you use the most recently released official IOCCC submission
packaging tool (hereby referred to as mkiocccentry(1)), which we STRONGLY
recommend you do (see also Rule 17), then the mkiocccentry(1)
-tool will warn you if there appears to be a Rule 2a violation.
-| The mkiocccentry(1) tool will give you the option of overriding the Rule 2a warning.
+tool will warn you if there appears to be a Rule 2a violation.
+
+
+The mkiocccentry(1) tool will give you the option of overriding the Rule 2a warning.
Overriding a Rule 2a warning carries a fair amount of risk that your submission
will be rejected. Be sure to consult the IOCCC guidelines
-ahead of time if you plan to override the Rule 2a warning.
-| If you do override the Rule 2a warning from the
+ahead of time if you plan to override the Rule 2a warning.
+
+
+If you do override the Rule 2a warning from the
mkiocccentry(1) tool, or otherwise plan to violate Rule 2a, then
you MUST CLEARLY EXPLAIN THE RATIONALE of why you are doing so in your
remarks.md file. Even if you do explain this in your remarks.md file your
-submission may still be rejected.
-| You may check your code prior to submission by giving the filename
-as a command like argument to the iocccsize(1) tool. For example:
+submission may still be rejected.
+
+
+You may check your code prior to submission by giving the filename
+as a command like argument to the iocccsize(1) tool. For example:
+
./iocccsize prog.c
Rule 2b
-| When the filename of your program source is given as a command line argument to the latest version
+
+When the filename of your program source is given as a command line argument to the latest version
of the official IOCCC size tool (hereby referred to as iocccsize(1)), the
-value printed should NOT exceed 2503.
-| The source to iocccsize(1) may be found in the
-mkiocccentry repo.
-| If you use the mkiocccentry(1) tool, which we STRONGLY recommend
+value printed should NOT exceed 2503.
+
+
+The source to iocccsize(1) may be found in the
+mkiocccentry repo.
+
+
+If you use the mkiocccentry(1) tool, which we STRONGLY recommend
you do (again, see also Rule 17),
-then mkiocccentry(1) will invoke iocccsize(1) before packaging your submission.
-| The mkiocccentry(1) tool will give you the option of overriding the Rule 2b warning.
+then mkiocccentry(1) will invoke iocccsize(1) before packaging your submission.
+
+
+The mkiocccentry(1) tool will give you the option of overriding the Rule 2b warning.
Overriding a Rule 2b warning carries a fair amount of risk that your submission
will be rejected. Be sure to consult the IOCCC guidelines
-ahead of time if you plan to override the Rule 2b warning.
-| If you do override the Rule 2b warning from the mkiocccentry(1) tool,
+ahead of time if you plan to override the Rule 2b warning.
+
+
+If you do override the Rule 2b warning from the mkiocccentry(1) tool,
or otherwise plan to violate Rule 2a, then you MUST CLEARLY EXPLAIN THE RATIONALE
of why you are doing so in your remarks.md file. Even if you do explain this in your remarks.md file
-your submission may still be rejected.
-| You may check your code prior to submission by giving the filename
-as a command like argument to the iocccsize(1) tool. For example:
+your submission may still be rejected.
+
+
+You may check your code prior to submission by giving the filename
+as a command like argument to the iocccsize(1) tool. For example:
+
./iocccsize prog.c
Rule 3
@@ -533,20 +568,30 @@ the
How to enter FAQ.
To submit to an open IOCCC, you must use the IOCCC submit
server. Unless the IOCCC is open, that link will
likely be unresponsive.
-
| The submit URL should be active on or slightly before 2024-MMM-DD HH:MM:SS UTC.
-| XXX - date/time is TBD - XXX
+
+The submit URL should be active on or slightly before 2024-MMM-DD HH:MM:SS UTC.
+XXX - date/time is TBD - XXX
+
Please wait to submit your entries until after that time.
Rule 4
-
| If your submission is selected as a winner, it may be modified in order
-to fit into the structure of the Official IOCCC winner website.
-
| For example, your submission’s Makefile might be modified.
-
| Your source code will be the file prog.c. The compiled binary
+
+If your submission is selected as a winner, it may be modified in order
+to fit into the structure of the Official IOCCC winner website.
+
+
+For example, your submission’s Makefile might be modified.
+
+
+Your source code will be the file prog.c. The compiled binary
will be called prog. If you submission requires different filenames,
then modify your submission’s Makefile to COPY (NOT move)
-the files accordingly.
-
| See also Rule 5, Rule 18 and Rule 21.
+the files accordingly.
+
+
+See also Rule 5, Rule 18 and Rule 21.
+
Rule 5
@@ -559,10 +604,14 @@ file to a new filename and then modify that copy.
Rule 6
-
| I am not a rule, I am a free(void *human); ‼️
-
| while (!(ioccc(rule(you(are(number(6)))))) {
-| ha_ha_ha();
-| }
+
+I am not a rule, I am a free(void *human); ‼️
+
+
+ while (!(ioccc(rule(you(are(number(6)))))) {
+ ha_ha_ha();
+ }
+
Rule 7
@@ -570,7 +619,9 @@ file to a new filename and then modify that copy.
You (the author(s)) must own the contents of your submission OR
you must have permission from the owner(s) to submit their content
under the following license:
-
| CC BY-SA 4.0 DEED Attribution-ShareAlike 4.0 International
+
+CC BY-SA 4.0 DEED Attribution-ShareAlike 4.0 International
+
If you submit any content that is owned by others, you MUST
detail that ownership (i.e., who owns what) AND document the
permission you obtained.
@@ -578,14 +629,18 @@ permission you obtained.
Rule 8
-
| Entries must be received prior to the end of this IOCCC which is 2024-MMM-DD HH:MM:SS UTC.
-| XXX - date/time is TBD - XXX
+
+Entries must be received prior to the end of this IOCCC which is 2024-MMM-DD HH:MM:SS UTC.
+XXX - date/time is TBD - XXX
+
A confirmation of submission will be sent to the submitting email address
before the close of the contest.
Rule 9
-
| Each person may submit up to and including 10.000000 entries per contest.
+
+Each person may submit up to and including 10.000000 (ten) entries per contest.
+
Each submission must be submitted separately.
Rule 10
@@ -611,25 +666,33 @@ their rule abuse is legal, in the
remarks.md file.
Rule 13
-
| Any C source that fails to compile because of unescaped octets with
-the high bit set (octet value >= 128) might be rejected.
+
+Any C source that fails to compile because of unescaped octets with
+the high bit set (octet value >= 128) might be rejected.
+
Rule 14
-
| Any C source that fails to compile because of lines with trailing
-control-M’s (i.e., lines with a tailing octet 015) might be rejected.
+
+Any C source that fails to compile because of lines with trailing
+control-M’s (i.e., lines with a tailing octet 015) might be rejected.
+
Please do NOT put trailing control-M’s on remarks file lines.
Please check to be sure, before submitting, that you have removed
any control-M at the end of remark file lines.
Rule 15
-
| In order to register for the IOCCC, you MUST have a valid email address.
+
+In order to register for the IOCCC, you MUST have a valid email address.
+
The judges are not responsible for delays in email, please plan
enough time for one automated exchange of email as part of your
submission.
-
| See the FAQ on how to register for the IOCCC in the
-FAQ for details.
+
+See the FAQ on how to register for the IOCCC in the
+FAQ for details.
+
Rule 16
@@ -641,168 +704,323 @@ been published may be disqualified.
Rule 17
TL;DR Rule 17 - Use mkiocccentry(1)
-
| This is a COMPLEX rule. Violating this rule will cause your submission to REJECTED!
+
+This is a COMPLEX rule. Violating this rule will cause your submission to REJECTED!
To help you avoid such a rejection, you are HIGHLY ENCOURAGED to use the mkiocccentry(1) tool,
based on the latest release of the mkiocccentry repo,
-to form your submission’s xz compressed tarball.
-
| The mkiocccentry repo
-contains IMPORTANT tools such as:
+to form your submission’s xz compressed tarball.
+
+
+The mkiocccentry repo
+contains IMPORTANT tools such as:
+
-
| The above mentioned tools will help you verify that your submission
-conforms to Rule 17.
-
| Each above mentioned tools has a -h option that provides command
-line help. For additional details, see the tools’ man pages.
-
| You do not explicitly need to invoke jparse(1) but the jparse(8)
-library will be used when compiling various tools.
+
+The above mentioned tools will help you verify that your submission
+conforms to Rule 17.
+
+
+Each above mentioned tools has a -h option that provides command
+line help. For additional details, see the tools’ man pages.
+
+
+You do not explicitly need to invoke jparse(1) but the jparse(8)
+library will be used when compiling various tools.
+
+
+Of course you can invoke jparse(1) if you wish to validate your own JSON
+data file or some other JSON file.
+
Rule 17 - The COMPLEX details
-
| Each submission MUST be in the form of a xz compressed tarball.
-
| The xz compressed tarball filename must be of the form:
+
+Each submission MUST be in the form of a xz compressed tarball.
+The xz compressed tarball filename must be of the form:
+
^submit.username-slot_num.[1-9][0-9]{9,}.txz$
-
| where username is your IOCCC registration username in the form of a
+
+… where username is your IOCCC registration username in the form of a
UUID (see
RFC 9562 for
details), and where slot_num is a single decimal digit integer
-(i.e., >= 0 and < 9).
-| In particular, username is in the form of:
+(i.e., >= 0 and < 9).
+
+
+In particular, username is in the form of:
xxxxxxxx-xxxx-4xxx-axxx-xxxxxxxxxxxx where x is a hexadecimal digit in the
range [0-9a-f]. And yes, there is a 4 (UUID version 4) and an a (UUID variant
-1) in there.
-| Your xz compressed tarball MUST contain, at a minimum,
-the following files:
+1) in there.
+
+
+Your xz compressed tarball MUST contain, at a minimum, the following files:
+
-Makefileprog.cremarks.md.info.json.auth.json
+Makefile
+
+prog.c
+
+remarks.md
+
+.info.json
+
+.auth.json
+
-
| The .info.json must be valid JSON and pass the chkentry(1) tests.
-
| The .auth.json must be valid JSON and pass the chkentry(1) tests.
-
| You submission may have additional files, however the filenames of those additional files MUST:
-
| * Be less than 100 characters in length
-| * Match the regular expression: ^[0-9A-Za-z][0-9A-Za-z._+-]*$
-
| The mkiocccentry(1) tool will not package any files that do not meet
-those requirements.
-
| The Makefile must be a non-empty file in GNU
-Makefile form. See the
+
+The .info.json must be valid JSON and pass the chkentry(1) tests.
+It is generated by the mkiocccentry(1) tool.
+
+
+The .auth.json must be valid JSON and pass the chkentry(1) tests.
+It is generated by the mkiocccentry(1) tool.
+
+
+You submission may have additional files, however the filenames of those additional files MUST:
+
+
+
+The mkiocccentry(1) tool will not package any files that do not meet
+those requirements.
+
+
+The Makefile MUST be a non-empty file in GNU
+Makefile form. See the
Makefile.example,
the FAQ about your submission’s Makefile and
-the FAQ about IOCCC Makefile compatibility for help.
-
| The remarks.md must be a non-empty file in markdown form. See also
+the FAQ about IOCCC Makefile compatibility for help.
+
+
+The remarks.md MUST be a non-empty file in markdown form. See also
Rule 18 and our FAQ about what to put in your
-remarks.md.
-
| The xz compressed tarball file MUST be less than
-or equal 3999971 octets in size.
-
| When your submission’s xz compressed tarball is uncompressed,
+remarks.md and the FAQ about IOCCC best markdown
+practices.
+
+
+See also the markdown syntax guide
+and the CommonMark Spec.
+
+
+
+The xz compressed tarball file MUST be less than or equal 3999971 octets in size.
+
+
+When your submission’s xz compressed tarball is uncompressed,
the total size of your submission: the sum of the size of the program,
hints, comments, build and info files MUST be less than or equal
-to 28314624 octets (27651K) in size.
-
| Your submission’s xz compressed tarball MUST pass the txzchk(1) test.
-
| You are HIGHLY ENCOURAGED to use the mkiocccentry(1)
-tool to form your submission’s xz compressed tarball.
-
| Your entry may NOT have subdirectories.
-
| Filenames in your entry (that is, not including the files generated by
-the mkiocccentry(1) tool or the tools it invokes) MUST:
+to
28314624 octets (
27651K) in size.
+
+
+Your submission’s xz compressed tarball MUST pass the txzchk(1) test. See
+the guidelines for more details on this tool.
+
+
+You are HIGHLY ENCOURAGED to use the mkiocccentry(1) tool to form your
+submission’s xz compressed tarball. See the guidelines for
+more details on this tool and the mkiocccentry
+repo.
+
+
+Your entry may NOT have subdirectories. However, you can provide files that
+are in different directories as mkiocccentry(1) will copy them to the work
+directory (see the guidelines for more details).
+
+
+Filenames in your entry (that is, not including the files generated by the
+mkiocccentry(1) tool or the tools it or any other tool invokes) MUST:
+
-- Be less than 100 characters in length
-- NOT have a
/ (excluding the entry directory that the
-mkiocccentry(1) tool generates).
-- NOT contain a path component of:
. (that is, with the exception of
-files generated by mkiocccentry(1) itself, it must have NO .).
-- NOT contain a path component of:
.. (that is, NO ..).
-- Match the regular expression
^[0-9A-Za-z][0-9A-Za-z._+-]*$ (again, excluding
-files generated by mkiocccentry(1)).
+
+Be less than 100 characters in length
+
+NOT have a / (excluding the entry directory that
+the mkiocccentry(1) tool generates).
+
+NOT contain a path component of: . (that is, with
+the exception of files generated by mkiocccentry(1) itself, it must have
+NO .).
+
+NOT contain a path component of: .. (that is,
+NO ..).
+
+Match the regular expression
+^[0-9A-Za-z][0-9A-Za-z._+-]*$ (again, excluding files generated by
+mkiocccentry(1)).
+
-
| Additionally, the tarball MUST have the following files (generated
-by the mkiocccentry(1) tool):
+
+Additionally, the tarball MUST have the following files (generated
+by the mkiocccentry(1) tool):
+
-
| The txzchk(1) tool will verify these (and other things) for you and
+
+The txzchk(1) tool will verify these (and other things) for you and
the chkentry(1) tool will do additional checks on the contents of the
-.auth.json and .info.json files.
-
| The tarball filename MUST pass fnamchk(1); the tool txzchk(1)
+.auth.json and .info.json files including JSON validity. If these checks
+fail it is an error and mkiocccentry(1) will fail. In this case it is very
+possibly a bug; please report it at the mkiocccentry issues
+page.
+
+
+The tarball filename MUST pass fnamchk(1); the tool txzchk(1)
will run fnamchk(1) as part of its algorithm. If you use mkiocccentry(1)
there should be no problem but if you were to package things manually it is
-possible there could be a problem.
-
| The fnamchk(1), which txzchk(1) executes, will verify that the
-filename is correct.
-
| These checks MUST PASS.
-
| Where Rule 17 and the tools from the latest
+possible there could be a problem and this is a big risk.
+
+
+The fnamchk(1), which txzchk(1) executes, will verify that the
+filename is correct.
+
+
+These checks MUST PASS.
+
+
+Where Rule 17 and the tools from the latest
release of the mkiocccentry repo
conflict, the IOCCC Judges will use their best judgment which
-is likely to favor mkiocccentry repo code.
-
| This means you should MAKE SURE that you use mkiocccentry(1) to
+is likely to favor mkiocccentry repo code.
+
+
+This means you should MAKE SURE that you use mkiocccentry(1) to
package your submission; mkiocccentry(1) will run the above mentioned tools
(that do not act on the tarball) before creating the tarball and after the
tarball is created it will then verify that the tarball is okay by running
-txzchk(1) on it.
-
| These tools will link in the jparse(8) library and chkentry(1)
-actually uses the parser to validate the
-JSON.
-
| If you run into a problem with one or more of these tools, PLEASE
-report it at the mkiocccentry issues
-page, making sure to run
-bug_report.sh. See the guidelines for help here and also
-read the FAQ about reporting bugs in the mkiocccentry
-repo.
-
| To state the obvious: submissions that violate Rule 17 will be rejected,
-so be sure to use the latest release of the mkiocccentry repo,
-to form and test your submission’s xz compressed tarball.
+
txzchk(1) on it.
+
+
+MAKE SURE you use the correct release of the repository; you should do this
+AFTER the contest opens (pull any changes or if you prefer download the
+repository via the download option at GitHub).
+
+
+We recommend that you run make and then install the tools (and man pages) via
+make install (as root or using sudo(1) to help you run these tools from your
+submission’s directory. The make install will install in /usr/local.
+
+
+These tools will link in the jparse(8) library; chkentry(1) uses the parser
+to validate the JSON but the other tools
+use parts of the library as well.
+
+
+If you run into a problem with one or more of these tools, PLEASE report it
+at the mkiocccentry issues
+page,
+making sure to run bug_report.sh. See the guidelines
+for help here and also read the FAQ about reporting bugs in the mkiocccentry
+repo.
+
+
+At the risk of stating the obvious: submissions that violate Rule
+17 will be rejected, so be sure to use the latest release of the
+mkiocccentry repo, to form and test
+your submission’s xz compressed tarball. Do NOT assume you have the most
+recent release without pulling or downloading via GitHub and make sure you
+do this AFTER the contest status has changed to
+open.
+
Rule 18
The entirety of your submission must be submitted under the following license:
-
| CC BY-SA 4.0 DEED Attribution-ShareAlike 4.0 International
+
+CC BY-SA 4.0 DEED Attribution-ShareAlike 4.0 International
+
You (the author(s)) MUST own the contents of your submission OR
you MUST HAVE PERMISSION from the owner(s) to submit their content.
-
You must not submit anything that cannot be submitted under that license.
+
You MUST NOT submit anything that cannot be submitted under that license.
Rule 19
-
| The remarks.md file, a required non-empty file, must be written in
-markdown format. See the Daring Fireball Markdown:
-Basics.
-
| We currently use pandoc to convert markdown to HTML.
-
| Please see our FAQ about what to put in your
+
+The remarks.md file, a required non-empty file, must be written in
+markdown format. See the Daring Fireball Markdown:
+Basics.
+
+
+We currently use pandoc to convert markdown to HTML.
+
+
+Please see our FAQ about what to put in your
remarks.md and the IOCCC markdown
-guidelines for additional markdown guidance.
+guidelines for additional markdown guidance.
+
Rule 20
The how to build instructions must be in Makefile format. See the FAQ about
make(1) compatibility the IOCCC
supports for more details.
-
| You are ENCOURAGED to use
+
+You are ENCOURAGED to use
Makefile.example,
-renamed as Makefile of course, for help in constructing your Makefile.
+renamed as
Makefile of course, for help in constructing your
Makefile.
+
The target of the Makefile must be called prog. The original
C source file must be called prog.c.
-
To invoke the C compiler, use ${CC}.
-To invoke the C preprocessor use ${CPP}.
-
Do not assume that . (the current directory) is in the $PATH.
-
| Your Makefile MUST use a syntax that is compatible with bash
+
To invoke the C compiler, use ${CC}. To invoke the C preprocessor use
+${CPP}.
+
Do NOT assume that . (the current directory) is in the $PATH.
+
+Your Makefile MUST use a syntax that is compatible with bash(1)
and GNU make(1). You are ENCOURAGED to use set SHELL= bash in
-your Makefile.
-
| Assume that commands commonly found in Single UNIX
+your Makefile.
+
+
+Assume that commands commonly found in Single UNIX
Specification
environments and systems that conform to the Single UNIX
Specification are
-available in the $PATH search path.
+available in the
$PATH search path.
+
Rule 21
-
Your submission must NOT create or modify files above the current directory
-with the exception of the /tmp and the /var/tmp directories. Your submission
+
Your submission MUST NOT create or modify files above the current directory
+with the exception of the /tmp and the /var/tmp directories. Your submission
MAY create subdirectories below the current directory, or in /tmp,
or in /var/tmp provided that . is NOT the first octet in any
directory name or filename you create.
@@ -810,13 +1028,13 @@ directory name or filename you create.
Rule 22
Catch 22:
-Your source code, data files, remarks and program output must NOT
-identify the authors of your code. The judges STRONGLY prefer to
-NOT know who is submitting entries to the IOCCC.
+Your source code, data files, remarks and program output MUST NOT
+identify the authors of your code. The judges STRONGLY PREFER to
+NOT know who is submitting entries to the IOCCC.
Even if you are a previous IOCCC winner, catch 22 still applies.
Identifying the author(s) of your submission in an obvious way anywhere
within your code, data, remarks or program output (unless you are
-Peter Honeyman or pretending to be Peter Honeyman) will be grounds
+Peter Honeyman or pretending to be Peter Honeyman) will be grounds
for disqualification of your submission.
Yes, Virginia, WE REALLY MEAN IT!
@@ -830,43 +1048,62 @@ for disqualification of your submission.
Rule 25
-
| The IOCCC rule set needs more than 5^2 rules: see Rule 26.
+
+The IOCCC rule set needs more than 5^2 rules: see Rule 26.
+
Rule 26
-
| “The quick brown fox jumps over the lazy dog”.
-| “Pack my box with five dozen liquor jugs.”
-| “How vexingly quick daft zebras jump!”
-| “Sphinx of black quartz, judge my vow.”
-| “Waltz, bad nymph, for quick jigs vex.”
-| “Mr. Jock, TV quiz PhD, bags few lynx.”
-| “abcdefg, hijklmnop, qrstu&v, wxy&z.”
+
+“The quick brown fox jumps over the lazy dog”.
+“Pack my box with five dozen liquor jugs.”
+“How vexingly quick daft zebras jump!”
+“Sphinx of black quartz, judge my vow.”
+“Waltz, bad nymph, for quick jigs vex.”
+“Mr. Jock, TV quiz PhD, bags few lynx.”
+“abcdefg, hijklmnop, qrstu&v, wxy&z.”
+
Rule 27
-
| Unless otherwise needed, Rule 27 is reserved for something cubic. :-)
+
+Unless otherwise needed, Rule 27 is reserved for something cubic. :-)
+
Rule 28
-
| Rule 28 is a perfect way end to the list of IOCCC rules as we do NOT plan to have 496 rules. :-)
+
+Rule 28 is a perfect way end to the list of IOCCC rules
+as we do NOT plan to have 496 rules. :-)
+
-
| For questions or comments about the contest, see Contacting the IOCCC.
-
| Be sure to review the IOCCC Rules and Guidelines as
+
+For questions or comments about the contest, see Contacting the IOCCC.
+
+
+Be SURE to review the IOCCC Rules and Guidelines as
IOCCC rules and the IOCCC guidelines may (and
-often do) change from year to year.
-
| You should be sure you have the current IOCCC rules and
-IOCCC guidelines prior to submitting entries.
-
| See the Official IOCCC website news for additional information.
-
| For the updates and breaking IOCCC news, you are encouraged to follow
+often do) change from year to year.
+
+
+You should be sure you have the current IOCCC rules and
+IOCCC guidelines prior to submitting entries.
+
+
See the Official IOCCC website news for additional information.
+
+For the updates and breaking IOCCC news, you are encouraged to follow
the IOCCC on Mastodon account. See our
FAQ about Mastodon for more information. Please do note that unless
you are mentioned by us you will NOT get a notification from the app so you
-should refresh the page even if you do follow us.
-
| Check out the Official IOCCC winner website in general.
+should refresh the page
even if you do follow us.
+
+
+Check out the Official IOCCC winner website in general.
+
Leonid A. Broukhis
chongo (Landon Curt Noll) /\cc/\
diff --git a/next/rules.md b/next/rules.md
index 12d911e41..7e3ea6387 100644
--- a/next/rules.md
+++ b/next/rules.md
@@ -31,7 +31,9 @@ app from time to time to view IOCCC mastodon updates.
# 28th International Obfuscated C Code Contest Official Rules
-**`|`** Copyright © 2024 Leonid A. Broukhis and Landon Curt Noll.
+
+Copyright © 2024 Leonid A. Broukhis and Landon Curt Noll.
+
All Rights Reserved. Permission for personal, education or non-profit use is
granted provided this this copyright and notice are included in its entirety
@@ -43,7 +45,9 @@ writing by [contacting the judges](../contact.html).
## IOCCC Rules version
+These [IOCCC rules](rules.html) are version **28.5 2024-07-08**.
+
**IMPORTANT**: Be sure to read the [IOCCC guidelines](guidelines.html).
@@ -52,10 +56,13 @@ writing by [contacting the judges](../contact.html).
### Change marks
-**`|`** **← Lines that start with this symbol indicate a change from the previous IOCCC**
+
+**← Lines that start with this symbol indicate a change from the previous IOCCC**
+
Most lines (we sometimes make mistakes) that were modified since the previous
-IOCCC start with the **`|`** symbol.
+IOCCC start with a solid 4 pixel black left border (or, in the case of a code
+block or blockquote, just a vertical bar).
@@ -89,13 +96,17 @@ The goals of the IOCCC:
# Important IOCCC dates
-**`|`** This IOCCC runs from **2024-MMM-DD HH:MM:SS UTC** to **202x-MMM-DD HH:MM:SS UTC**.
-**`|`** **XXX - date/time is TBD - XXX**
+
+This IOCCC runs from **2024-MMM-DD HH:MM:SS UTC** to **202x-MMM-DD HH:MM:SS UTC**.
+**XXX - date/time is TBD - XXX**
+
-**`|`** Until the start of this IOCCC, these [IOCCC rules](rules.html),
+
+Until the start of this IOCCC, these [IOCCC rules](rules.html),
[IOCCC guidelines](guidelines.html) and the [mkiocccentry
toolkit](https://github.com/ioccc-src/mkiocccentry) should be considered
provisional **BETA** versions and **may be adjusted _AT ANY TIME_**.
+
When the IOCCC is open, the submission URL is:
[https://submit.ioccc.org](https://submit.ioccc.org); at all other
@@ -104,8 +115,10 @@ times that link is likely to be unresponsive.
Please check the [How to enter FAQ](../faq.html#submit)
for **important information** on how to submit to the IOCCC.
-**`|`** The submit URL should be active on or slightly before **2024-MMM-DD HH:MM:SS UTC**.
-**`|`** **XXX - date/time is TBD - XXX**
+
+The submit URL should be active on or slightly before **2024-MMM-DD HH:MM:SS UTC**.
+**XXX - date/time is TBD - XXX**
+
Please wait to submit your entries until after that time.
@@ -151,26 +164,36 @@ The size rule requires your submission to satisfy **BOTH** [Rule 2a](#rule2a) an
## Rule 2a
-**`|`** The size of your program source **should not exceed 4993 bytes**.
+
+The size of your program source **should not exceed 4993 bytes**.
+
-**`|`** If you use the most recently released official IOCCC submission
+
+If you use the most recently released official IOCCC submission
packaging tool (hereby referred to as `mkiocccentry(1)`), which we **STRONGLY
recommend you do** (see also [Rule 17](#rule17)), then the `mkiocccentry(1)`
tool will warn you if there appears to be a [Rule 2a](#rule2a) violation.
+
-**`|`** The `mkiocccentry(1)` tool will give you the option of overriding the [Rule 2a](#rule2a) warning.
+
+The `mkiocccentry(1)` tool will give you the option of overriding the [Rule 2a](#rule2a) warning.
Overriding a [Rule 2a](#rule2a) warning carries a **fair amount of risk that your submission
will be rejected**. Be sure to consult the [IOCCC guidelines](guidelines.html)
ahead of time if you plan to override the [Rule 2a](#rule2a) warning.
+
-**`|`** If you do override the [Rule 2a](#rule2a) warning from the
+
+If you do override the [Rule 2a](#rule2a) warning from the
`mkiocccentry(1)` tool, or otherwise plan to violate [Rule 2a](#rule2a), then
you **MUST CLEARLY EXPLAIN THE RATIONALE** of why you are doing so in your
`remarks.md` file. **_Even if you do_ explain this in your `remarks.md` file your
submission may still be rejected**.
+
-**`|`** You may check your code prior to submission by giving the filename
+
+You may check your code prior to submission by giving the filename
as a command like argument to the `iocccsize(1)` tool. For example:
+
```
./iocccsize prog.c
@@ -181,29 +204,41 @@ as a command like argument to the `iocccsize(1)` tool. For example:
## Rule 2b
-**`|`** When the filename of your program source is given as a command line argument to the latest version
+
+When the filename of your program source is given as a command line argument to the latest version
of the official IOCCC size tool (hereby referred to as `iocccsize(1)`), the
value printed **should NOT exceed _2503_**.
+
-**`|`** The source to `iocccsize(1)` may be found in the
+
+The source to `iocccsize(1)` may be found in the
[mkiocccentry repo](https://github.com/ioccc-src/mkiocccentry).
+
-**`|`** If you use the `mkiocccentry(1)` tool, which we **STRONGLY recommend
+
+If you use the `mkiocccentry(1)` tool, which we **STRONGLY recommend
you do** (again, see also [Rule 17](#rule17)),
then `mkiocccentry(1)` will invoke `iocccsize(1)` before packaging your submission.
+
-**`|`** The `mkiocccentry(1)` tool will give you the option of overriding the [Rule 2b](#rule2b) warning.
+
+The `mkiocccentry(1)` tool will give you the option of overriding the [Rule 2b](#rule2b) warning.
Overriding a [Rule 2b](#rule2b) warning carries a **fair amount of risk that your submission
will be rejected**. Be sure to consult the [IOCCC guidelines](guidelines.html)
ahead of time if you plan to override the [Rule 2b](#rule2b) warning.
+
-**`|`** If you do override the [Rule 2b](#rule2b) warning from the `mkiocccentry(1)` tool,
+
+If you do override the [Rule 2b](#rule2b) warning from the `mkiocccentry(1)` tool,
or otherwise plan to violate [Rule 2a](#rule2b), then you **MUST CLEARLY EXPLAIN THE RATIONALE**
of why you are doing so in your `remarks.md` file. **_Even if you do_ explain this in your `remarks.md` file
your submission may still be rejected**.
+
-**`|`** You may check your code prior to submission by giving the filename
+
+You may check your code prior to submission by giving the filename
as a command like argument to the `iocccsize(1)` tool. For example:
+
```
./iocccsize prog.c
@@ -220,8 +255,10 @@ To submit to an open IOCCC, you must use the [IOCCC submit
server](https://submit.ioccc.org/). Unless the IOCCC is open, that link will
likely be unresponsive.
-**`|`** The submit URL should be active on or slightly before **2024-MMM-DD HH:MM:SS UTC**.
-**`|`** **XXX - date/time is TBD - XXX**
+
+The submit URL should be active on or slightly before **2024-MMM-DD HH:MM:SS UTC**.
+**XXX - date/time is TBD - XXX**
+
**Please wait to submit** your entries until after that time.
@@ -230,17 +267,25 @@ likely be unresponsive.
## Rule 4
-**`|`** If your submission is selected as a winner, it may be modified in order
+
+If your submission is selected as a winner, it may be modified in order
to fit into the structure of the [Official IOCCC winner website](https://www.ioccc.org/index.html).
+
-**`|`** For example, your submission's `Makefile` might be modified.
+
+For example, your submission's `Makefile` might be modified.
+
-**`|`** Your source code will be the file `prog.c`. The compiled binary
+
+Your source code will be the file `prog.c`. The compiled binary
will be called `prog`. If you submission requires different filenames,
then modify your submission's `Makefile` to **COPY** (**NOT** move)
the files accordingly.
+
-**`|`** See also [Rule 5](#rule5), [Rule 18](#rule18) and [Rule 21](#rule21).
+
+See also [Rule 5](#rule5), [Rule 18](#rule18) and [Rule 21](#rule21).
+
@@ -260,11 +305,15 @@ file to a new filename and then modify that copy.
## Rule 6
-**`|`** I am not a rule, I am a `free(void *human);` ‼️
+
+I am not a rule, I am a `free(void *human);` ‼️
+
-**`|`** `while (!(ioccc(rule(you(are(number(6)))))) {`
-**`|`** `ha_ha_ha();`
-**`|`** `}`
+
+ `while (!(ioccc(rule(you(are(number(6)))))) {`
+ `ha_ha_ha();`
+ `}`
+
@@ -277,7 +326,9 @@ You (the author(s)) must own the contents of your submission OR
you must have permission from the owner(s) to submit their content
under the following license:
-**`|`** **[CC BY-SA 4.0 DEED Attribution-ShareAlike 4.0 International](https://creativecommons.org/licenses/by-sa/4.0/)**
+
+**[CC BY-SA 4.0 DEED Attribution-ShareAlike 4.0 International](https://creativecommons.org/licenses/by-sa/4.0/)**
+
If you submit any content that is owned by others, you **MUST
detail that ownership** (i.e., who owns what) **_AND_ document the
@@ -290,8 +341,10 @@ Please note that the IOCCC size tool is **NOT** an original work.
## Rule 8
-**`|`** **XXX - date/time is TBD - XXX**
+
+Entries must be received prior to the end of this IOCCC which is **2024-MMM-DD HH:MM:SS UTC**.
+**XXX - date/time is TBD - XXX**
+
A confirmation of submission will be sent to the submitting email address
@@ -302,7 +355,9 @@ before the close of the contest.
## Rule 9
-**`|`** Each person may submit up to and including **10.000000** entries per contest.
+
+Each person may submit up to and including **10.000000** (ten) entries per contest.
+
**Each submission _must be submitted separately_**.
@@ -341,16 +396,20 @@ their rule abuse is legal, in the `remarks.md` file.
## Rule 13
-**`|`** Any C source that fails to compile because of unescaped octets with
+
+Any C source that fails to compile because of unescaped octets with
the high bit set (octet value >= 128) **_might_** be rejected.
+
## Rule 14
-**`|`** Any C source that fails to compile because of lines with trailing
+
+Any C source that fails to compile because of lines with trailing
control-M's (i.e., lines with a tailing octet `015`) **_might_** be rejected.
+
Please do **NOT** put trailing control-M's on remarks file lines.
Please check to be sure, before submitting, that you have removed
@@ -361,15 +420,18 @@ any control-M at the end of remark file lines.
## Rule 15
-**`|`** In order to register for the IOCCC, you **MUST** have a valid email address.
+
+In order to register for the IOCCC, you **MUST** have a valid email address.
+
The judges **are not responsible for delays in email**, please plan
enough time for one automated exchange of email as part of your
submission.
-**`|`** See [the FAQ on how to register for the IOCCC](../faq.html#register) in the
+
+See [the FAQ on how to register for the IOCCC](../faq.html#register) in the
[FAQ](../faq.html) for details.
-
+
## Rule 16
@@ -388,156 +450,256 @@ been published may be disqualified.
### TL;DR Rule 17 - Use `mkiocccentry(1)`
-**`|`** This is a **COMPLEX** rule. **Violating this rule will cause your submission to REJECTED**!
+
+This is a **COMPLEX** rule. **Violating this rule will cause your submission to REJECTED**!
To help you avoid such a rejection, you are **HIGHLY ENCOURAGED** to use the `mkiocccentry(1)` tool,
based on the latest release of the [mkiocccentry repo](https://github.com/ioccc-src/mkiocccentry),
to form your submission's xz compressed tarball.
+
-**`|`** The [mkiocccentry repo](https://github.com/ioccc-src/mkiocccentry)
+
+The [mkiocccentry repo](https://github.com/ioccc-src/mkiocccentry)
contains **IMPORTANT** tools such as:
+
-* `chkentry(1)`
-* `iocccsize(1)`
-* `mkiocccentry(1)`
-* `txzchk(1)`
-* `fnamchk(1)`
-* `jparse(1)` and `jparse(8)` (which `chkentry(1)` uses)
+*
`chkentry(1)`
+*
`iocccsize(1)`
+*
`mkiocccentry(1)`
+*
`txzchk(1)`
+*
`fnamchk(1)`
+*
`jparse(1)` and `jparse(8)` (which `chkentry(1)` uses)
-**`|`** The above mentioned tools will help you verify that your submission
+
+The above mentioned tools will help you verify that your submission
conforms to [Rule 17](#rule17).
+
-**`|`** Each above mentioned tools has a `-h` option that provides command
+
+Each above mentioned tools has a `-h` option that provides command
line help. For additional details, see the tools' man pages.
+
-**`|`** You do not explicitly need to invoke `jparse(1)` but the `jparse(8)`
+
+You do not explicitly need to invoke `jparse(1)` but the `jparse(8)`
library will be used when compiling various tools.
+
+
+
+Of course you **can** invoke `jparse(1)` if you wish to validate your own JSON
+data file or some other JSON file.
+
### Rule 17 - The COMPLEX details
-**`|`** Each submission **MUST** be in the form of a xz compressed tarball.
-
-**`|`** The xz compressed tarball filename must be of the form:
+
+Each submission **MUST** be in the form of a xz compressed tarball.
+The xz compressed tarball filename must be of the form:
+
```
^submit.username-slot_num.[1-9][0-9]{9,}.txz$
```
-**`|`** where _`username`_ is your IOCCC registration username **in the form of a
+
+... where _`username`_ is your IOCCC registration username **in the form of a
[UUID](https://en.wikipedia.org/wiki/Universally_unique_identifier)** (see
[RFC 9562](https://datatracker.ietf.org/doc/html/rfc9562) for
details), and where _`slot_num`_ is a single decimal digit integer
(i.e., >= `0` and < `9`).
+
-**`|`** In particular, _`username`_ is in the form of:
+
+In particular, _`username`_ is in the form of:
`xxxxxxxx-xxxx-4xxx-axxx-xxxxxxxxxxxx` where `x` is a hexadecimal digit in the
range `[0-9a-f]`. And yes, there is a 4 (UUID version 4) and an `a` (UUID variant
1) in there.
+
-**`|`** Your xz compressed tarball **MUST** contain, at a minimum,
-the following files:
+
+Your xz compressed tarball **MUST** contain, **at a minimum**, the following files:
+
-* `Makefile`
-* `prog.c`
-* `remarks.md`
-* `.info.json`
-* `.auth.json`
+*
`Makefile`
+*
`prog.c`
+*
`remarks.md`
+*
`.info.json`
+*
`.auth.json`
-**`|`** The `.info.json` must be valid JSON and pass the `chkentry(1)` tests.
+
+The `.info.json` must be valid JSON and pass the `chkentry(1)` tests.
+It is generated by the `mkiocccentry(1)` tool.
+
-**`|`** The `.auth.json` must be valid JSON and pass the `chkentry(1)` tests.
+
+The `.auth.json` must be valid JSON and pass the `chkentry(1)` tests.
+It is generated by the `mkiocccentry(1)` tool.
+
-**`|`** You submission may have additional files, however the filenames of those additional files **MUST**:
+
+You submission may have additional files, however the filenames of those additional files **MUST**:
+
-**`|`** * Be less than **100** characters in length
-**`|`** * Match the regular expression: `^[0-9A-Za-z][0-9A-Za-z._+-]*$`
+*
Be less than **100** characters in length.
+*
Match the regular expression:
+`^[0-9A-Za-z][0-9A-Za-z._+-]*$`
-**`|`** The `mkiocccentry(1)` tool will not package any files that do not meet
+
+The `mkiocccentry(1)` tool will not package any files that do not meet
those requirements.
+
-**`|`** The `Makefile` must be a non-empty file in [GNU
-Makefile](https://www.gnu.org/software/make/manual/make.html) form. See the
+
+The `Makefile` **MUST** be a **non**-empty file in **[GNU
+Makefile](https://www.gnu.org/software/make/manual/make.html)** form. See the
[Makefile.example](https://github.com/ioccc-src/mkiocccentry/blob/master/Makefile.example),
the [FAQ about your submission's Makefile](../faq.html#submission_makefiles) and
the [FAQ about IOCCC Makefile compatibility](../faq.html#make_compatibility) for help.
+
-**`|`** The `remarks.md` must be a non-empty file in markdown form. See also
+
+The `remarks.md` **MUST** be a **non**-empty file in markdown form. See also
[Rule 18](#rule18) and our [FAQ about what to put in your
-remarks.md](../faq.html#remarks_md).
+remarks.md](../faq.html#remarks_md) and the [FAQ about IOCCC best markdown
+practices](../faq.html#markdown).
+
-**`|`** The xz compressed tarball file **MUST** be less than
-or equal **3999971** octets in size.
+
+See also the [markdown syntax](https://www.markdownguide.org/basic-syntax) guide
+and the [CommonMark Spec](https://spec.commonmark.org/current/).
+
-**`|`** When your submission's xz compressed tarball is uncompressed,
+
+The xz compressed tarball file **MUST** be less than or equal **3999971** octets in size.
+
+
+
+When your submission's xz compressed tarball is uncompressed,
the total size of your submission: the sum of the size of the program,
hints, comments, build and info files **MUST** be less than or equal
to **28314624** octets (**27651K**) in size.
+
-**`|`** Your submission's xz compressed tarball **MUST** pass the `txzchk(1)` test.
+
+Your submission's xz compressed tarball **MUST** pass the `txzchk(1)` test. See
+the [guidelines](guidelines.html) for more details on this tool.
+
-**`|`** You are **HIGHLY ENCOURAGED** to use the `mkiocccentry(1)`
-tool to form your submission's xz compressed tarball.
+
+You are **HIGHLY ENCOURAGED** to use the `mkiocccentry(1)` tool to form your
+submission's xz compressed tarball. See the [guidelines](guidelines.html) for
+more details on this tool and the [mkiocccentry
+repo](https://github.com/ioccc-src/mkiocccentry).
+
-**`|`** Your entry may **NOT** have subdirectories.
+
+Your entry may **NOT** have subdirectories. However, you can provide files that
+are in different directories as `mkiocccentry(1)` will copy them to the work
+directory (see the [guidelines](guidelines.html) for more details).
+
-**`|`** Filenames in your entry (that is, not including the files generated by
-the `mkiocccentry(1)` tool or the tools it invokes) **MUST**:
+
+Filenames in your entry (that is, not including the files generated by the
+`mkiocccentry(1)` tool or the tools it or any other tool invokes) **MUST**:
+
-* Be less than **100** characters in length
-* **NOT** have a **`/`** (excluding the entry directory that the
-`mkiocccentry(1)` tool generates).
-* **NOT** contain a path component of: **`.`** (that is, with the exception of
-files generated by `mkiocccentry(1)` itself, it must have **NO** **`.`**).
-* **NOT** contain a path component of: **`..`** (that is, **NO** **`..`**).
-* Match the regular expression `^[0-9A-Za-z][0-9A-Za-z._+-]*$` (again, excluding
-files generated by `mkiocccentry(1)`).
+*
Be less than **100** characters in length
+*
**NOT** have a **`/`** (excluding the entry directory that
+the `mkiocccentry(1)` tool generates).
+*
**NOT** contain a path component of: **`.`** (that is, with
+the exception of files generated by `mkiocccentry(1)` itself, it must have
+**NO** **`.`**).
+*
**NOT** contain a path component of: **`..`** (that is,
+**NO** **`..`**).
+*
Match the regular expression
+`^[0-9A-Za-z][0-9A-Za-z._+-]*$` (again, excluding files generated by
+`mkiocccentry(1)`).
-**`|`** Additionally, the tarball **MUST** have the following files (generated
+
+Additionally, the tarball **MUST** have the following files (generated
by the `mkiocccentry(1)` tool):
+
-* `.auth.json` which contains information about the author or authors (that will
-only be looked at if the submission wins).
-* `.info.json` which contains information about the entry.
+*
`.auth.json` which contains information about the author or
+authors (that will only be looked at if the submission wins).
+*
`.info.json` which contains information about the
+entry.
-**`|`** The `txzchk(1)` tool will verify these (and other things) for you and
+
+The `txzchk(1)` tool will verify these (and other things) for you and
the `chkentry(1)` tool will do additional checks on the contents of the
-`.auth.json` and `.info.json` files.
+`.auth.json` and `.info.json` files including JSON validity. If these checks
+fail it is an error and `mkiocccentry(1)` will fail. In this case it is very
+**possibly** a bug; please [report it at the mkiocccentry issues
+page](https://github.com/ioccc-src/mkiocccentry/issues/new?assignees=&labels=bug&projects=&template=bug_report.yml&title=%5BBug%5D+%3Ctitle%3E).
+
-**`|`** The tarball filename **MUST** pass `fnamchk(1)`; the tool `txzchk(1)`
+
+The tarball filename **MUST** pass `fnamchk(1)`; the tool `txzchk(1)`
will run `fnamchk(1)` as part of its algorithm. If you use `mkiocccentry(1)`
there should be no problem but if you were to package things manually it is
-possible there could be a problem.
+possible there could be a problem and this is a big risk.
+
-**`|`** The `fnamchk(1)`, which `txzchk(1)` executes, will verify that the
+
+The `fnamchk(1)`, which `txzchk(1)` executes, will verify that the
filename is correct.
+
-**`|`** These checks **MUST PASS**.
+
+These checks **MUST PASS**.
+
-**`|`** Where [Rule 17](#rule17) and the tools from the latest
+
+Where [Rule 17](#rule17) and the tools from the latest
release of the [mkiocccentry repo](https://github.com/ioccc-src/mkiocccentry)
conflict, the [IOCCC Judges](../judges.html) will use their best judgment which
is likely to favor [mkiocccentry repo](https://github.com/ioccc-src/mkiocccentry) code.
+
-**`|`** This means you should **MAKE SURE** that you use `mkiocccentry(1)` to
+
+This means you should **MAKE SURE** that you use `mkiocccentry(1)` to
package your submission; `mkiocccentry(1)` will run the above mentioned tools
(that do not act on the tarball) **before** creating the tarball and after the
tarball is created it will then verify that the tarball is okay by running
`txzchk(1)` on it.
+
-**`|`** These tools will link in the `jparse(8)` library and `chkentry(1)`
-actually uses the parser to validate the
-[JSON](https://www.json.org/json-en.html).
+
+**MAKE SURE** you use the correct release of the repository; you should do this
+**AFTER** the contest opens (pull any changes or if you prefer download the
+repository via the download option at GitHub).
+
-**`|`** If you run into a problem with one or more of these tools, **PLEASE**
-report it at the [mkiocccentry issues
-page](https://github.com/ioccc-src/mkiocccentry/issues), **making sure to run
-`bug_report.sh`**. See the [guidelines](guidelines.html) for help here and also
-read [the FAQ about reporting bugs in the mkiocccentry
+
+We recommend that you run `make` and then install the tools (and man pages) via
+`make install` (as root or using `sudo(1)` to help you run these tools from your
+submission's directory. The `make install` will install in `/usr/local`.
+
+
+
+These tools will link in the `jparse(8)` library; `chkentry(1)` uses the parser
+to validate the [JSON](https://www.json.org/json-en.html) but the other tools
+use parts of the library as well.
+
+
+
+If you run into a problem with one or more of these tools, **PLEASE** [report it
+at the mkiocccentry issues
+page](https://github.com/ioccc-src/mkiocccentry/issues/new?assignees=&labels=bug&projects=&template=bug_report.yml&title=%5BBug%5D+%3Ctitle%3E),
+**making sure to run `bug_report.sh`**. See the [guidelines](guidelines.html)
+for help here and also read [the FAQ about reporting bugs in the mkiocccentry
repo](../faq.html#mkiocccentry_bugs).
+
-**`|`** To state the obvious: submissions that violate [Rule 17](#rule17) **will be rejected**,
-so be sure to use the latest release of the [mkiocccentry repo](https://github.com/ioccc-src/mkiocccentry),
-to form and test your submission's xz compressed tarball.
+
At the risk of stating the obvious: submissions that violate [Rule
+17](#rule17) **will be rejected**, so **be sure** to use the latest release of the
+[mkiocccentry repo](https://github.com/ioccc-src/mkiocccentry), to form and test
+your submission's xz compressed tarball. Do **NOT** assume you have the most
+recent release without pulling or downloading via GitHub and **make sure** you
+do this **AFTER** the [contest status](../status.html) has changed to
+[open](../status.html#open).
+
@@ -546,27 +708,35 @@ to form and test your submission's xz compressed tarball.
The entirety of your submission must be submitted under the following license:
-**`|`** **[CC BY-SA 4.0 DEED Attribution-ShareAlike 4.0 International](https://creativecommons.org/licenses/by-sa/4.0/)**
+
+**[CC BY-SA 4.0 DEED Attribution-ShareAlike 4.0 International](https://creativecommons.org/licenses/by-sa/4.0/)**
+
You (the author(s)) **MUST** own the contents of your submission **OR**
you **MUST HAVE PERMISSION** from the owner(s) to submit their content.
-You must not submit anything that cannot be submitted under that license.
+You **MUST NOT** submit anything that cannot be submitted under that license.
## Rule 19
-**`|`** The `remarks.md` file, a required non-empty file, must be written in
-markdown format. See the Daring Fireball [Markdown:
+
+The `remarks.md` file, a required non-empty file, must be written in
+markdown format. See the [Daring Fireball Markdown:
Basics](http://daringfireball.net/projects/markdown/basics).
+
-**`|`** We currently use [pandoc](https://pandoc.org) to convert markdown to HTML.
+
+We currently use [pandoc](https://pandoc.org) to convert markdown to HTML.
+
-**`|`** Please see our [FAQ about what to put in your
+
+Please see our [FAQ about what to put in your
remarks.md](../faq.html#remarks_md) and the [IOCCC markdown
guidelines](../markdown.html) for additional markdown guidance.
+
@@ -577,35 +747,41 @@ The how to build instructions must be in Makefile format. See [the FAQ about
make(1) compatibility the IOCCC
supports](../faq.html#make_compatibility) for more details.
-**`|`** You are **ENCOURAGED** to use
+
+You are **ENCOURAGED** to use
[Makefile.example](https://github.com/ioccc-src/mkiocccentry/blob/master/Makefile.example),
-renamed as `Makefile` of course, for help in constructing your Makefile.
+renamed as `Makefile` of course, for help in constructing your `Makefile`.
+
The target of the Makefile must be called `prog`. The original
C source file must be called `prog.c`.
-To invoke the C compiler, use `${CC}`.
-To invoke the C preprocessor use `${CPP}`.
+To invoke the C compiler, use `${CC}`. To invoke the C preprocessor use
+`${CPP}`.
-Do not assume that `.` (the current directory) is in the `$PATH`.
+Do **NOT** assume that `.` (the current directory) is in the `$PATH`.
-**`|`** Your `Makefile` **MUST** use a syntax that is compatible with bash
+
+Your `Makefile` **MUST** use a syntax that is compatible with `bash(1)`
and GNU `make(1)`. You are **ENCOURAGED** to use set `SHELL= bash` in
your `Makefile`.
+
-**`|`** Assume that commands commonly found in [Single UNIX
+
+Assume that commands commonly found in [Single UNIX
Specification](https://en.wikipedia.org/wiki/Single_UNIX_Specification)
environments and systems that conform to the [Single UNIX
Specification](https://en.wikipedia.org/wiki/Single_UNIX_Specification) are
available in the `$PATH` search path.
+
## Rule 21
-Your submission **must NOT** create or modify files above the current directory
-with the exception of the `/tmp` and the `/var/tmp` directories. Your submission
+Your submission **MUST NOT** create or modify files above the current directory
+_with the exception of_ the `/tmp` and the `/var/tmp` directories. Your submission
**MAY** create subdirectories below the current directory, or in `/tmp`,
or in `/var/tmp` provided that `.` is **NOT** the first octet in any
directory name or filename you create.
@@ -617,15 +793,15 @@ directory name or filename you create.
Catch 22:
-Your source code, data files, remarks and program output **must NOT**
-identify the authors of your code. The judges **STRONGLY prefer** to
-NOT know who is submitting entries to the IOCCC.
+Your source code, data files, remarks and program output **MUST NOT**
+identify the authors of your code. The judges **STRONGLY PREFER** to
+**NOT** know who is submitting entries to the IOCCC.
Even if you are a previous IOCCC winner, catch 22 still applies.
Identifying the author(s) of your submission in an obvious way anywhere
within your code, data, remarks or program output (unless you are
-_Peter Honeyman_ or pretending to be _Peter Honeyman_) will be grounds
+**Peter Honeyman** or pretending to be **Peter Honeyman**) will be grounds
for disqualification of your submission.
Yes, Virginia, **WE REALLY MEAN IT!**
@@ -649,34 +825,41 @@ Even though 24 is not prime, you should still see [Rule 23](#rule23).
## Rule 25
-**`|`** The [IOCCC rule set](rules.html) needs more than 5^2 rules: see [Rule 26](#rule26).
+
+The [IOCCC rule set](rules.html) needs more than 5^2 rules: see [Rule 26](#rule26).
+
## Rule 26
-**`|`** "The quick brown fox jumps over the lazy dog".
-**`|`** "Pack my box with five dozen liquor jugs."
-**`|`** "How vexingly quick daft zebras jump!"
-**`|`** "Sphinx of black quartz, judge my vow."
-**`|`** "Waltz, bad nymph, for quick jigs vex."
-**`|`** "Mr. Jock, TV quiz PhD, bags few lynx."
-**`|`** "abcdefg, hijklmnop, qrstu&v, wxy&z."
+> "The quick brown fox jumps over the lazy dog".
+> "Pack my box with five dozen liquor jugs."
+> "How vexingly quick daft zebras jump!"
+> "Sphinx of black quartz, judge my vow."
+> "Waltz, bad nymph, for quick jigs vex."
+> "Mr. Jock, TV quiz PhD, bags few lynx."
+> "abcdefg, hijklmnop, qrstu&v, wxy&z."
## Rule 27
-**`|`** Unless otherwise needed, [Rule 27](#rule27) is reserved for something cubic. :-)
+
+Unless otherwise needed, [Rule 27](#rule27) is reserved for something cubic. :-)
+
## Rule 28
-**`|`** [Rule 28](#rule28) is a perfect way end to the list of [IOCCC rules](rules.html) as we do **NOT** plan to have **496** rules. :-)
+
+[Rule 28](#rule28) is a perfect way end to the list of [IOCCC rules](rules.html)
+as we do **NOT** plan to have **496** rules. :-)
+
@@ -685,24 +868,34 @@ Even though 24 is not prime, you should still see [Rule 23](#rule23).
-**`|`** For questions or comments about the contest, see [Contacting the IOCCC](../contact.html).
+
+For questions or comments about the contest, see [Contacting the IOCCC](../contact.html).
+
-**`|`** Be sure to review the [IOCCC Rules and Guidelines](index.html) as
+
+**Be SURE** to review the [IOCCC Rules and Guidelines](index.html) as
[IOCCC rules](rules.html) and the [IOCCC guidelines](guidelines.html) may (and
**often do**) change from year to year.
+
-**`|`** You should be sure you have the current [IOCCC rules](rules.html) and
+
+You should be sure you have the current [IOCCC rules](rules.html) and
[IOCCC guidelines](guidelines.html) prior to submitting entries.
+
-**`|`** See the [Official IOCCC website news](../news.html) for additional information.
+See the [Official IOCCC website news](../news.html) for additional information.
-**`|`** For the updates and breaking IOCCC news, you are encouraged to follow
+
+For the updates and breaking IOCCC news, you are encouraged to follow
the [IOCCC on Mastodon](https://fosstodon.org/@ioccc) account. See our
[FAQ about Mastodon](../faq.html#try_mastodon) for more information. Please do note that unless
you are mentioned by us you will **NOT** get a notification from the app _so you
should refresh the page **even if you do follow us**_.
+
-**`|`** Check out the [Official IOCCC winner website](https://www.ioccc.org/index.html) in general.
+
+Check out the [Official IOCCC winner website](https://www.ioccc.org/index.html) in general.
+
**Leonid A. Broukhis**