To submit your code to the IOCCC, you MUST follow these steps:
Check the current status of the IOCCC see of the IOCCC is open.
@@ -1542,8 +1544,10 @@ include this here, at least for now.Usually the index.html file will explain how to use it under Linux so we do not include this here, at least for now.
While we know that use of -Weverything is generally not recommended
by clang C compiler developers, we do use the -Weverything
option in a certain case in IOCCC entry Makefiles.
| XXX - date/time is TBD - XXX
| The reason for the times of day are so that key IOCCC events are calculated
for be a functional UTC time. :-)
Until the start of this IOCCC, the IOCCC rules, IOCCC guidelines and iocccsize.c
-(contained in the mkiocccentry
-toolkit)
-tool should be considered provisional BETA versions and may be
-adjusted AT ANY TIME.
The IOCCC submission URL is https://submit.ioccc.org/.
+| Until the start of this IOCCC, the IOCCC rules,
+IOCCC guidelines tools in the
+mkiocccentry repo, tool 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
Please wait to submit your entries until after that time.
-The IOCCC rules, IOCCC guidelines and iocccsize.c (invoked by the mkiocccentry) -tool 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 entry -submission URL.
+| 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.
| Use default way to compile submissions is now -std=gnu17 -O3 -g3 -Wall -Wextra -pedantic.
| Submissions are in the form of a single bzip2 compressed tarball.
| To assist in the formation of the bzip2 compressed tarball for submission, use the
+mkiocccentry(1) tool as found in the mkiocccentry repo.
| Rule 17 as been significantly modified
+to account for the new mkiocccentry repo tools.
| An example Makefile
+is now available from the mkiocccentry repo.
| The IOCCC submission URL, when the IOCCC is open, is submit.ioccc.org.
You are encouraged to examine the winners of previous contests. See FOR MORE INFORMATION for details on how to get previous winners.
Keep in mind that rules change from year to year, so some winning entries might not be valid entries this year. What was unique and novel one year might be ‘old’ the next year.
-An entry is usually examined in a number of ways. We typically apply -a number of tests to an entry:
+An submission is usually examined in a number of ways. We typically apply +a number of tests to an submission:
You should consider how your entry looks in each of the above tests. -You should ask yourself if your entry remains obscure after it has been +
You should consider how your submission looks in each of the above tests. +You should ask yourself if your submission remains obscure after it has been ‘cleaned up’ by the C pre-processor and a C beautifier.
-Your entry need not pass all of the above tests. In certain +
Your submission need not pass all of the above tests. In certain cases, a test is not important. Entries that compete for the ‘strangest/most creative source layout’ need not do as well as others in terms of their algorithm. On the other hand, given -two such entries, we are more inclined to pick the entry that +two such entries, we are more inclined to pick the submission that does something interesting when you run it.
We try to avoid limiting creativity in our rules. As such, we leave the contest open for creative rule interpretation. As in real life programming, interpreting a requirements document or a customer request is important. For this reason, we often award ‘Best abuse of the -rules’ or ‘Worst abuse of the rules’ to an entry that illustrates this point +rules’ or ‘Worst abuse of the rules’ to an submission that illustrates this point in an ironic way.
We do realize that there are holes in the rules, and invite entries to attempt to exploit them. We will award ‘Worst abuse of the rules’ or @@ -480,18 +490,18 @@ to attempt to exploit them. We will award ‘Worst abuse of the rules
| Even so, we will attempt to use the smallest plug needed, 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 an entry that has a slight problem, particularly +the effort to debug an 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
number printer that claims that
16 is a prime number. If you do have a bug, you are better off
-documenting it. Noting “this entry sometimes prints the 4th power
-of a prime by mistake” would save the above entry. And sometimes,
-a strange bug/feature can even help the entry! Of course, a correctly
-working entry is best. Clever people will note that 16 might be prime
+documenting it. Noting “this submission sometimes prints the 4th power
+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 entry’s remarks.md file.
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.
@@ -504,12 +514,12 @@ misleading comments and variable names might be a good start. 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 toolkit for the iocccsize(1) tool.
| 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 entry must satisfy BOTH the maximum size Rule 2a AND your entry
+
| Your submission must satisfy BOTH the maximum size Rule 2a AND your submission
must satisfy the IOCCC size tool Rule 2b.
This tool imposes a 2nd limit on C code size (see Rule 2a. To check your +
| This IOCCC size tool imposes a 2nd limit on C code size (see Rule 2a. To check your
code against the 2nd limit of Rule 2, use the -i command line option.
For example:
./iocccsize prog.c#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 4096 to 4993: a change that keeps the “2b to 2a” size ratio to a value similar to the 2001-2020 IOCCC era.
We applaud programs that do not issue warnings when compiled.
-To avoid warnings, you might be tempted to add various -Wno-foobar
-flags. Unfortunately such flags are NOT portable. Moreover,
-such flags are not consistent between different C compilers.
-Therefore we recommend that you consider one of several approaches:
| 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-2020 IOCCC era.
| We recommend that you use the
+example Makefile
+from the IOCCC mkiocccentry repo.
+renamed as Makefile of course, as the starting point for your submissions
+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 -O3 -std=gnu17.
| It is OK to require your submission to not be compiled
+using the default -O3 -g3 -std=gnu17 settings. Simply explain why
+your submission should not be compiled using -O3 -g3 -std=gnu17 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:
CSTD= -std=c17| For compilers, such as clang, that have the -Weverything option,
+while you try wish it, HOWEVER see the FAQ about clang -Weverything.
+Thus, we do NOT recommend that you put the use of -Weverything into
+your submission’s Makefile.
| You may change the level of optimization and compiler debug level
+which your submission is compiled by modifying the COPT Makefile variable.
+For example, to compile without optimization:
COPT= -O0 -g3| 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.
| To turn off a compiler warning, to 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 also adding -Wno-unknown-warning-option just in case the
+warning you use is not available in the compilers we use test your
+submission.
| If you need to define something on the compile line, use
+the CDEFINE Makefile variable. For example:
CDEFINE= -Dfoo -Dbar=baz| If need add other “magic” flags to your compile line,
+use the COTHER Makefile variable. For example:
COTHER= -include stdio.h| 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, integrate it into
+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
@@ -561,32 +610,19 @@ as a program that is more well rounded in confusion.
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 suggest that you compile your entry with a commonly available
-gnu17 (ISO C 2017 with GNU extensions) C compiler.
We really 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:
-Wall -Wextra -pedanticFor compilers, such as clang, that have the -Weverything option, try
-to make your code compile warning free using:
-Wall -Wextra -Weverything -pedantic.. though, again, see the FAQ about clang -Weverything in -the FAQ.
-If you must turn off various warnings on the compile line such as:
- ... -Wno-empty-body -Wno-return-type ...| be sure to clearly state so in your remarks.md file AS WELL AS in
-your Makefile.
CWARN= -Wall -Wextra -pedanticAll other things being equal, a program that must turn off fewer warnings will be considered better, for certain values of better.
-| Unless you clearly state otherwise in your remarks.md file AS WELL AS in
-your “how to build” / Makefile we will compile using:
-O3 -std=gnu17| 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. Just add the needed “-Wno-somethings” to your Makefile. We suggest you add then to the CSILENCE= line, if you use some variant of the example Makefile from the IOCCC mkiocccentry repo.
| If you do add “-Wno-somethings” to your Makefile, consider also adding -Wno-unknown-warning-option just in case the warning you use is not available in the compilers we use test your submission.
| DO NOT assume that we will use gcc to compile your program.
-We will first try to compile your program using clang.
It is much better to not use any obscure compiler flags if -you can help it. We want to discourage the use of obscure compiler -flags that would make the program less portable.
+| 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
+if either gcc or clang does 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:
main() {
@@ -595,15 +631,14 @@ of nested functions such as:
}
| please_dont_submit_this();
}This is because such nested functions often requires one to compile with
-a flag such as -fnested-functions that is not found on some compilers.
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 commonly used C compilers. Sorry!
| We DISLIKE submissions 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 entry uses functions that have a variable number of +
If your submission uses functions that have a variable number of
arguments, be careful. Systems implement va_list as a wide variety
of ways. Because of this, a number of operations using va_list are
not portable and must not be used:
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 entry should assume that exit(3) returns a void.
int, your submission should assume that exit(3) returns a void.
| 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 @@ -640,7 +675,7 @@ a one-liner in our vague opinion.
| * dump core or have compiler warnings (it is OK only if you warn us in your ‘remark,md’ file)| * dump core or have compiler warnings (it is OK only if you warn us in your ‘remark.md’ file)| * won’t compile or run a Single UNIX Specification environmentIn order to encourage entry portability, we DISLIKE entries that +
In order to encourage submission portability, we DISLIKE entries that fail to build unless one is using an IDE. For example, do not mandate that one must use Microsoft Visual Studio to compile -your entry. Nevertheless some of the better IDEs have command-line +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 Specification environment Therefore do not assume the system has a
windows.h include file:
There are at least zero judges who think that Fideism has little or nothing to do with the IOCCC judging process.
Don’t forget that the building of your program should be done -WITHOUT human intervention. So don’t do things such as:
+WITHOUT human intervention. So don’t do things such as: prog: prog.c
#echo this next line requires data from standard input
cat > prog.c
@@ -727,9 +762,9 @@ of code, and the other that is formatted more like a typical C
program, we tend to favor the second version. Of course, a third
version of the same program that is formatted in an interesting
and/or obfuscated way, would definitely win over the first two!
-Remember, you can submit more than one entry. See the IOCCC rules for details.
+Remember, you can submit more than one submission. See the IOCCC rules for details.
We suggest that you avoid trying for the ‘smallest self-replicating’
-source. The smallest, a zero byte entry, won in 1994.
+source. The smallest, a zero byte submission, won in 1994.
Programs that claim to be the smallest C source that does something, really
better be the smallest such program or they risk being rejected because
they do not work as documented.
@@ -798,7 +833,7 @@ 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 entry 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.
@@ -826,18 +861,18 @@ Instead of unescaped octets, you should use or escapes:
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
-think your entry is obfuscated. This is particularly true if
-your entry is has some very subtle obfuscations that we might
+think your submission is obfuscated. This is particularly true if
+your submission is 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 entry using a “normal” formatting style +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) the code might pass for non-obfuscated C. Deceptive comments, and misleading formatting, in some cases, may be a plus. On the other hand, a misleading code style requires more source bytes.
If you do elect to use misleading formatting and comments, we suggest you remark on this point in your remarks where you talk -about why you think your entry is obfuscated. On the other hand, +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 processor. @@ -859,48 +894,49 @@ interesting than simply implementing the IOCCC size tool algorithm.
to pick, choose a 64-bit word size.If we 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 entry +an emulator of 60-bit CDC Cyber CPU, we might just try your submission on that emulator as well :-)
-If your entry MUST run only in 32-bit mode on an Intel processor, add the +
If your submission MUST run only in 32-bit mode on an Intel processor, add the following compiler flag:
-arch i386to your “how to build” make compile line. For example:
prog: prog.c
${CC} prog.c -arch i386 -o progBe even more creative!
-| If there are limitations in your entry, 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
-entry factors values up to a certain size, you might want to state:
This entry factors values up 2305567963945518424753102147331756070.
+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.
The judges might try to factor the value -5, so you want to might state:
- This entry factors positive values up 2305567963945518424753102147331756070.
+ This submission factors positive values up 2305567963945518424753102147331756070.
Attempting to factor large values will produce unpredictable results.
However the judges might try to also factor 0, so you want to might state:
- This entry factors values between 1 and 2305567963945518424753102147331756070.
+ This submission factors values between 1 and 2305567963945518424753102147331756070.
Attempting to factor values outside that range will produce unpredictable results.
Moreover the try to also factor 3.5 or 0x7, or Fred, so you want to might state:
- This entry factors integers between 1 and 2305567963945518424753102147331756070.
+ This submission factors integers between 1 and 2305567963945518424753102147331756070.
Attempting to factor anything else will produce unpredictable results.
-You entry might be better off catching the attempt to factor bogus values
+
You submission might be better off catching the attempt to factor bogus values
and doing something interesting. So you might want to code accordingly and state:
- This entry factors integers between 1 and 2305567963945518424753102147331756070.
+ This submission factors integers between 1 and 2305567963945518424753102147331756070.
Attempting to factor anything else will cause the program to insult your pet fish Eric.
The judges might not have a pet fish named Eric, so might want to state:
- This entry factors integers between 1 and 2305567963945518424753102147331756070.
+ This submission factors integers between 1 and 2305567963945518424753102147331756070.
Attempting to factor anything else will cause the program to insult your pet fish Eric,
or in the case that you lack such a pet, will insult the pet that you do not have.
-When all other things are equal, an entry with fewer limitations will be judged
-better than an entry with lots of limitations. So you might want to code accordingly
+
When all other things are equal, an submission with fewer limitations will be judged
+better than an submission with lots of limitations. So you might want to code accordingly
and state:
- This entry attempts to a factor value of any size provided that the program is
+ This submission attempts to a factor value of any size provided that the 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 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 annoys us when be comes to 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.
-| We LIKE a reading remarks.md files, especially if they contain useful, informative, and even humorous content about your entry. Yes, this is a hint. :-)
+| 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 a 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. :-)
ABUSING THE RULES:
Legal abuse of the IOCCC rules is somewhat encouraged. Legal rule abuse
@@ -911,27 +947,27 @@ submitted.
entries, regardless of if they receive an award, result in changes to
the next year’s IOCCC rules and IOCCC guidelines.
Legal abuse of the IOCCC rules is NOT an invitation to violate the
-IOCCC rules. An entry that violates the rules in the
+IOCCC rules. An submission that violates the rules in the
opinion of the judges, WILL be
disqualified. RULE ABUSE CARRIES A CERTAIN LEVEL OF RISK! If you
-have an entry that might otherwise be interesting, you might want to
+have an submission that might otherwise be interesting, you might want to
submit two versions; one that does not abuse the IOCCC rules and one that
does.
| 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 entry is valid. Humor and/or creativity help plead a case.
+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
2a and/or about Rule 2b
-and submit an entry anyway, you MUST try to justify why the IOCCC
-judges should not reject your entry due to a rule violation.
+and submit an 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
-entry rather than on the submission process itself.
+submission rather than on the submission process itself.
We are often asked why the contest IOCCC rules and
IOCCC guidelines seem too
strange or contain mistakes, flaws or grammatical errors. One reason
@@ -954,8 +990,8 @@ This is one of the reasons why the IOCCC rules and
IOCCC guidelines are written in obfuscated form.
JUDGING PROCESS:
Entries are judged by Leonid A. Broukhis and Landon Curt Noll.
-Each entry submitted is given a random id number and subdirectory. The
-entry files including, but not limited to prog.c, Makefile (that we
+
Each submission submitted is given a random id number and subdirectory. The
+submission files including, but not limited to prog.c, Makefile (that we
form from around your “how to build” information), as well as any
data files that you submit are all placed under their own directory
stored and judged from this directory.
@@ -965,7 +1001,7 @@ won an award. Because we do not read this information for entries that
do not win, we do not know who did not win.
The above process helps keep us biased for/against any one particular
individual. Therefore you MUST refrain from putting any information
-that reveals your identity in your entry.
+that reveals your identity in your submission.
Now some people point out that coding style might reveal the information
about the others. However we consider this to be simply circumstantial
and outside the scope of the above paragraph.
@@ -975,12 +1011,12 @@ Honeyman. The judges are on to this trick
and therefore consider any obfuscated source or data file claiming to be from
Honeyman to not be form Honeyman. This of course creates an interesting paradox
known as the “obfuscated Peter Honeyman paradox”. Should Peter Honeyman
-actually submit an obfuscated entry, he alone is excluded from the above, as we
+actually submit an obfuscated submission, he alone is excluded from the above, as we
will likely believe it just another attempt at confusion. This guideline is
known as the “Peter Honeyman is exempt” guideline.
BTW: None of the entries claiming to be from Peter Honeyman have ever
won an award. So it is theoretically possible that Peter Honeyman
-did submit an entry in the past. In the past, Peter had denied
+did submit an submission 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:
@@ -1003,7 +1039,7 @@ account.
the collection of entries are divided into two roughly equal piles;
the pile that advances on to the next round, and the pile that does
not. We also re-examine the entries that were eliminated in the
-previous round. Thus, an entry gets at least two readings.
+previous round. Thus, an submission gets at least two readings.
A reading consists of a number of actions:
- reading the “how to build” information and forming a Makefile
@@ -1023,11 +1059,11 @@ skipping over any #include files
miscellaneous tests on the source and binary.
| This is the very guideline that goes, BING!
Until we reduce the stack of entries down to about 25 entries, entries
-are judged on an individual basis. An entry is set aside because it
+are judged on an individual basis. An submission is set aside because it
does not, in our opinion, meet the standard established by the round.
When the number of entries thins to about 25 entries, we begin to form
award categories. Entries begin to compete with each other for awards.
-An entry will often compete in several categories.
+An submission will often compete in several categories.
The actual award category list will vary depending on the types of entries
we receive. A typical category list might be:
@@ -1054,28 +1090,28 @@ half that number: declaring those remaining to be winners.
the final round are definitely better than the ones that do not
make it. The selection of the winners out of the final round, is
less clear cut.
-Sometimes a final round entry is good enough to win, but is beat out
-by a similar, but slightly better entry. For this reason, it is
-sometimes worthwhile to re-enter an improved version of an entry
+
Sometimes a final round submission is good enough to win, but is beat out
+by a similar, but slightly better submission. For this reason, it is
+sometimes worthwhile to re-enter an improved version of an submission
that failed to win in a previous year. This assumes, of course,
-that the entry is worth improving in the first place!
+that the submission is worth improving in the first place!
More than one IOCCC judge has been known to bribe another IOCCC judge
-into voting for a winning entry by offering a bit high quality chocolate.
+into voting for a winning submission by offering a bit high quality chocolate.
This technique is highly discouraged for use by non-IOCCC judges.
-More often than not, we select a small entry (usually one line), a
-strange/creative layout entry. We sometimes also select an
-entry that abuses the IOCCC guidelines in an interesting way,
+
More often than not, we select a small submission (usually one line), a
+strange/creative layout submission. We sometimes also select an
+submission that abuses the IOCCC guidelines in an interesting way,
or that stretches the content rules that while legal, is
nevertheless goes against the intent of the rules.
-In the end, we traditionally pick one entry as ‘best’. Sometimes such
-an entry simply far exceeds any of the other entries. More often, the
+
In the end, we traditionally pick one submission as ‘best’. Sometimes such
+an submission simply far exceeds any of the other entries. More often, the
‘best’ is picked because it does well in a number of categories.
-In years past, we renamed the winning entry from prog.c to a
+
In years past, we renamed the winning submission from prog.c to a
name related to the submitter(s) names. This is no longer done.
Winning source is called prog.c A compiled binary is called prog.
ANNOUNCEMENT OF WINNERS:
The judges will toot initial announcement of who won, the name
-of their award, and a very brief description of the winning entry
+of their award, and a very brief description of the winning submission
from the @IOCCC Mastodon account. You should
follow us on Mastodon and refresh the page (even if you do follow us) as unless
you are mentioned you will not get a notification.
diff --git a/next/guidelines.md b/next/guidelines.md
index adb6c0298..51eecf1a0 100644
--- a/next/guidelines.md
+++ b/next/guidelines.md
@@ -68,25 +68,41 @@ The rules are typically published along with the [IOCCC guidelines](guidelines.h
**`|`** The reason for the times of day are so that key IOCCC events are **calculated**
for be a **fun**ctional UTC time. :-)
-Until the start of this IOCCC, the [IOCCC rules](rules.html), [IOCCC guidelines](guidelines.html) and `iocccsize.c`
-(contained in the [mkiocccentry
-toolkit](https://github.com/ioccc-src/mkiocccentry))
-tool should be considered provisional **BETA** versions and **may be
-adjusted _AT ANY TIME_**.
-
-The IOCCC submission URL is
**`|`** **XXX - date/time is TBD - XXX**
-Please wait to submit your entries until after that time.
+**`|`** The [IOCCC rules](rules.html), [IOCCC
+guidelines](guidelines.html) 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](../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 [IOCCC rules](rules.html), [IOCCC guidelines](guidelines.html) and iocccsize.c (invoked by the mkiocccentry)
-tool 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](../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 entry
-submission URL.
+**`|`** 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.
+
+**`|`** Use default way to compile submissions is now `-std=gnu17 -O3 -g3 -Wall -Wextra -pedantic`.
+
+**`|`** Submissions are in the form of a single bzip2 compressed tarball.
+
+**`|`** To assist in the formation of the bzip2 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) as been significantly modified
+to account for the new [mkiocccentry repo](https://github.com/ioccc-src/mkiocccentry) tools.
+
+**`|`** 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).
+
+**`|`** The IOCCC submission URL, [when the IOCCC is open](../status.html), is [submit.ioccc.org](https://submit.ioccc.org/).
# HINTS AND SUGGESTIONS:
@@ -98,8 +114,8 @@ Keep in mind that rules change from year to year, so some winning entries
might not be valid entries this year. What _was_ unique and novel one year
_might be 'old' the next year_.
-An entry is usually examined in a number of ways. We typically apply
-a number of tests to an entry:
+An submission is usually examined in a number of ways. We typically apply
+a number of tests to an submission:
* look at the original source
* convert ANSI trigraphs to ASCII
@@ -110,15 +126,15 @@ a number of tests to an entry:
* compile it (with flags to enable all warnings)
* execute it
-You should consider how your entry looks in each of the above tests.
-You should ask yourself if your entry remains obscure after it has been
+You should consider how your submission looks in each of the above tests.
+You should ask yourself if your submission remains obscure after it has been
'_cleaned up_' by the C pre-processor and a C beautifier.
-Your entry need not pass all of the above tests. In certain
+Your submission need not pass all of the above tests. In certain
cases, a test is not important. Entries that compete for the
'_strangest/most creative source layout_' need not do as well as
others in terms of their algorithm. On the other hand, given
-two such entries, we are more inclined to pick the entry that
+two such entries, we are more inclined to pick the submission that
does something interesting when you run it.
We try to avoid limiting creativity in our rules. As such, we leave
@@ -126,7 +142,7 @@ the contest open for creative rule interpretation. As in [real
life](https://en.wikipedia.org/wiki/Real_life)
programming, interpreting a requirements document or a customer request
is important. For this reason, we often award '_Best abuse of the
-rules_' or '_Worst abuse of the rules_' to an entry that illustrates this point
+rules_' or '_Worst abuse of the rules_' to an submission that illustrates this point
in an ironic way.
We do realize that there are holes in the rules, and invite entries
@@ -138,19 +154,19 @@ to attempt to exploit them. We will award '_Worst abuse of the rules_' or
**`|`** 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 an entry that has a slight problem, particularly
+the effort to debug an 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
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 entry sometimes prints the 4th power
-of a prime by mistake_" would save the above entry. And sometimes,
-a strange bug/feature can even help the entry! Of course, a correctly
-working entry is best. Clever people will note that 16 might be prime
+documenting it. Noting "_this submission sometimes prints the 4th power
+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 entry'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,
@@ -168,16 +184,16 @@ are considered more portable.
**`|`** [Rule 2](rules.html#rule2) (the size rule) refers to the use of the IOCCC size tool called `iocccsize(1)`.
-**`|`** See the [mkiocccentry toolkit](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**.
**`|`** The overall size limit (see [Rule 2a](rules.html#rule2a)) on `prog.c` is now **4993 bytes**.
-**`|`** Your entry must satisfy BOTH the maximum size [Rule 2a](rules.html#rule2a) AND your entry
+**`|`** Your submission must satisfy BOTH the maximum size [Rule 2a](rules.html#rule2a) AND your submission
must satisfy the IOCCC size tool [Rule 2b](rules.html#rule2b).
-This 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 the 2nd limit of [Rule 2](rules.html#rule2), use the -i command line option.
For example:
@@ -217,25 +233,94 @@ 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 4096 to 4993: a change that keeps the "2b to 2a" size ratio to a value similar to the [2001-2020 IOCCC era](../faq.html#size_rule).
+**`|`** 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-2020 IOCCC era](../faq.html#size_rule).
-We applaud programs that do not issue warnings when compiled.
-To avoid warnings, you might be tempted to add various `-Wno-foobar`
-flags. Unfortunately such flags are NOT portable. Moreover,
-such flags are not consistent between different C compilers.
-Therefore we recommend that you consider one of several approaches:
+**`|`** 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 submissions
+required `Makefile`. Feel free to modify the Makefile to suit your obfuscated needs.
-a) Write code that does not generate compiler warnings (but see [the FAQ about
-clang -Weverything](../faq.html#faq3_11))
-b) Do not use flags that disable compiler warnings
-c) Provide instructions (such as in your Makefile) that
- use the appropriate disable compiler warnings flags for
- both clang and gcc
-d) Do something creative
+**`|`** 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
+`-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 `-O3 -std=gnu17`.
+
+**`|`** It is **OK** to require your submission to not be compiled
+using the default `-O3 -g3 -std=gnu17` settings. Simply explain why
+your submission should not be compiled using `-O3 -g3 -std=gnu17` 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:
+
+```
+ CSTD= -std=c17
+```
+
+**`|`** For compilers, such as clang, that have the `-Weverything` option,
+while you try wish it, **HOWEVER** see the [FAQ about clang -Weverything](../faq.html#weverything).
+Thus, we do **NOT** recommend that you put the use of `-Weverything` into
+your submission's `Makefile`.
+
+**`|`** You may change the level of optimization and compiler debug level
+which your submission is compiled by modifying the `COPT` Makefile variable.
+For example, to compile without optimization:
+
+```
+ COPT= -O0 -g3
+```
+
+**`|`** 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.
+
+**`|`** To turn off a compiler warning, to 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 also adding `-Wno-unknown-warning-option` just in case the
+warning you use is not available in the compilers we use test your
+submission.
+
+**`|`** If you need to define something on the compile line, use
+the `CDEFINE` Makefile variable. For example:
+
+```
+ CDEFINE= -Dfoo -Dbar=baz
+```
+
+**`|`** If need add other "_magic_" flags to your compile line,
+use the `COTHER` Makefile variable. For example:
+
+```
+ COTHER= -include stdio.h
+```
# OUR LIKES AND DISLIKES:
+**`|`** 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, integrate it into
+the [Official IOCCC winner website](https://www.ioccc.org/index.html).
+
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
@@ -255,56 +340,26 @@ When declaring local or global variables, you should declare the type:
this_is_not; /* <-- Try to avoid implicit type declarations */
```
-**`|`** We suggest that you compile your entry with a commonly available
-gnu17 (ISO C 2017 with GNU extensions) C compiler.
-
-We really **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:
```
- -Wall -Wextra -pedantic
+ CWARN= -Wall -Wextra -pedantic
```
-For compilers, such as clang, that have the `-Weverything` option, try
-to make your code compile warning free using:
-
-```
- -Wall -Wextra -Weverything -pedantic
-```
-
-.. though, again, see [the FAQ about clang -Weverything](../faq.html#faq3_11) in
-the [FAQ](../faq.html).
-
-
-If you must turn off various warnings on the compile line such as:
-
-```
- ... -Wno-empty-body -Wno-return-type ...
-```
-
-**`|`** be sure to clearly state so in your `remarks.md` file **AS WELL AS** in
-your `Makefile`.
-
All other things being equal, a program that must turn off fewer
warnings will be considered better, for certain values of better.
-**`|`** Unless you clearly state otherwise in your `remarks.md` file **AS WELL AS** in
-your "how to build" / Makefile we will compile using:
+**`|`** We tend to **like less** a submission that requires either
+**gcc** or **clang**. We prefer submissions that can compile
+under both **gcc** and **clang**.
-```
- -O3 -std=gnu17
-```
+**`|`** We **RECOMMEND** that the compiler flags you use in your
+submission's `Makefile` are supported by both **gcc** and **clang**.
-**`|`** 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. Just add the needed "`-Wno-somethings`" to your Makefile. We suggest you add then to the `CSILENCE=` line, if you use some variant of the [example Makefile](https://github.com/ioccc-src/mkiocccentry/blob/master/Makefile.example) from the [IOCCC mkiocccentry repo](https://github.com/ioccc-src/mkiocccentry).
-
-**`|`** If you do add "`-Wno-somethings`" to your Makefile, consider also adding `-Wno-unknown-warning-option` just in case the warning you use is not available in the compilers we use test your submission.
-
-**`|`** **DO NOT** assume that we will use **gcc** to compile your program.
-We will first try to compile your program using **clang**.
-
-It is much better to not use any obscure compiler flags if
-you can help it. We want to discourage the use of obscure compiler
-flags that would make the program less portable.
+**`|`** We **DISLIKE** the use of obscure compiler flags, especially
+if either **gcc** or **clang** does 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:
@@ -318,18 +373,17 @@ of nested functions such as:
}
```
-This is because such nested functions often requires one to compile with
-a flag such as `-fnested-functions` that is not found on some compilers.
-
-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 commonly used C compilers. Sorry!
+actually implemented in both **gcc** and **clang**.
+
+**`|`** We **DISLIKE** submissions 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 entry uses functions that have a variable number of
+If your submission uses functions that have a variable number of
arguments, be careful. Systems implement `va_list` as a wide variety
of ways. Because of this, a number of operations using `va_list` are
not portable and must not be used:
@@ -349,7 +403,7 @@ 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 entry should assume that `exit(3)` returns a `void`.
+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.
@@ -374,7 +428,7 @@ We tend to **DISLIKE** programs that:
* are very hardware specific
* are very OS version specific (index/strchr differences are OK, but socket/streams specific code is likely not to be)
-**`|`** * dump core or have compiler warnings (it is OK only if you warn us in your 'remark,md' file)
+**`|`** * dump core or have compiler warnings (it is OK only if you warn us in your 'remark.md' file)
**`|`** * won't compile or run a [Single UNIX Specification](https://en.wikipedia.org/wiki/Single_UNIX_Specification) environment
* depend on a utility or application not normally found 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
@@ -387,10 +441,10 @@ We tend to **DISLIKE** programs that:
* that mandate the exclusive the use of an specific Integrated
* Development Environment (IDE)
-In order to encourage entry portability, we **DISLIKE** entries that
+In order to encourage submission portability, we **DISLIKE** entries that
fail to build unless one is using an IDE. For example, do not
mandate that one must use Microsoft Visual Studio to compile
-your entry. Nevertheless some of the better IDEs have command-line
+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 Specification](https://en.wikipedia.org/wiki/Single_UNIX_Specification) environment Therefore do not assume the system has a
@@ -441,7 +495,7 @@ There are at least zero judges who think that Fideism has little
or nothing to do with the IOCCC judging process.
Don't forget that the building of your program should be done
-***WITHOUT human intervention***. So don't do things such as:
+**WITHOUT human intervention**. So don't do things such as:
```
prog: prog.c
@@ -489,10 +543,10 @@ of code, and the other that is formatted more like a typical C
program, we tend to favor the second version. Of course, a third
version of the same program that is formatted in an interesting
and/or obfuscated way, would definitely win over the first two!
-Remember, you can submit more than one entry. See the [IOCCC rules](rules.html) for details.
+Remember, you can submit more than one submission. See the [IOCCC rules](rules.html) for details.
We suggest that you avoid trying for the 'smallest self-replicating'
-source. The smallest, a zero byte entry, [won in 1994](../1994/smr/index.html).
+source. The smallest, a zero byte submission, [won in 1994](../1994/smr/index.html).
Programs that claim to be the smallest C source that does something, really
better be the smallest such program or they risk being rejected because
@@ -591,7 +645,7 @@ 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 entry 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.
@@ -628,12 +682,12 @@ Instead of unescaped octets, you should use \octal or \hex escapes:
```
**`|`** It is a very good idea to, in your `remarks.md` file, tell us why you
-think your entry is obfuscated. This is particularly true if
-your entry is has some very subtle obfuscations that we might
+think your submission is obfuscated. This is particularly true if
+your submission is 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 entry using a "normal" formatting style
+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)
the code might pass for non-obfuscated C. Deceptive comments,
and misleading formatting, in some cases, may be a plus. On the
@@ -641,7 +695,7 @@ other hand, a misleading code style requires more source bytes.
If you do elect to use misleading formatting and comments, we
suggest you remark on this point in your remarks where you talk
-about why you think your entry is obfuscated. On the other hand,
+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!
@@ -669,10 +723,10 @@ to pick, choose a 64-bit word size.
If we 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 entry
+an emulator of 60-bit CDC Cyber CPU, we might just try your submission
on that emulator as well :-)
-If your entry MUST run only in 32-bit mode on an Intel processor, add the
+If your submission MUST run only in 32-bit mode on an Intel processor, add the
following compiler flag:
```
@@ -688,58 +742,58 @@ to your "how to build" make compile line. For example:
Be even more creative!
-**`|`** If there are limitations in your entry, 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
-entry 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 entry factors values up 2305567963945518424753102147331756070.
+ This submission factors values up 2305567963945518424753102147331756070.
Attempting to factor larger values will produce unpredictable results.
```
The judges might try to factor the value -5, so you want to might state:
```
- This entry factors positive values up 2305567963945518424753102147331756070.
+ This submission factors positive values up 2305567963945518424753102147331756070.
Attempting to factor large values will produce unpredictable results.
```
However the judges might try to also factor 0, so you want to might state:
```
- This entry factors values between 1 and 2305567963945518424753102147331756070.
+ This submission factors values between 1 and 2305567963945518424753102147331756070.
Attempting to factor values outside that range will produce unpredictable results.
```
Moreover the try to also factor 3.5 or 0x7, or Fred, so you want to might state:
```
- This entry factors integers between 1 and 2305567963945518424753102147331756070.
+ This submission factors integers between 1 and 2305567963945518424753102147331756070.
Attempting to factor anything else will produce unpredictable results.
```
-You entry might be better off catching the attempt to factor bogus values
+You submission might be better off catching the attempt to factor bogus values
and doing something interesting. So you might want to code accordingly and state:
```
- This entry factors integers between 1 and 2305567963945518424753102147331756070.
+ This submission factors integers between 1 and 2305567963945518424753102147331756070.
Attempting to factor anything else will cause the program to insult your pet fish Eric.
```
The judges might not have a pet fish named Eric, so might want to state:
```
- This entry factors integers between 1 and 2305567963945518424753102147331756070.
+ This submission factors integers between 1 and 2305567963945518424753102147331756070.
Attempting to factor anything else will cause the program to insult your pet fish Eric,
or in the case that you lack such a pet, will insult the pet that you do not have.
```
-When all other things are equal, an entry with fewer limitations will be judged
-better than an entry with lots of limitations. So you might want to code accordingly
+When all other things are equal, an submission with fewer limitations will be judged
+better than an submission with lots of limitations. So you might want to code accordingly
and state:
```
- This entry attempts to a factor value of any size provided that the program is
+ This submission attempts to a factor value of any size provided that the program is
given enough time and memory. If the value is not a proper integer, the program
might insult a fish named Eric.
```
@@ -752,7 +806,9 @@ and state:
**`|`** 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.
-**`|`** We **LIKE** a reading `remarks.md` files, especially if they contain useful, informative, and even humorous content about your entry. Yes, this is a **hint**. :-)
+**`|`** **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** a 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. :-)
@@ -771,10 +827,10 @@ entries, regardless of if they receive an award, result in changes to
the next year's [IOCCC rules](rules.html) and [IOCCC guidelines](guidelines.html).
Legal abuse of the [IOCCC rules](rules.html) is NOT an invitation to violate the
-[IOCCC rules](rules.html). An entry that violates the [rules](rules.html) in the
+[IOCCC rules](rules.html). An submission that violates the [rules](rules.html) in the
opinion of the judges, **WILL** be
disqualified. **_RULE ABUSE CARRIES A CERTAIN LEVEL OF RISK!_** If you
-have an entry that might otherwise be interesting, you might want to
+have an 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.
@@ -782,19 +838,19 @@ does.
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
-your entry is valid. Humor and/or creativity help plead a case.
+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
2a](rules.html#rule2a) and/or about [Rule 2b](rules.html#rule2b)
-and submit an entry anyway, you **MUST** try to justify why the IOCCC
-judges should not reject your entry due to a rule violation.
+and submit an 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
-entry rather than on the submission process itself.
+submission rather than on the submission process itself.
We are often asked why the contest [IOCCC rules](rules.html) and
[IOCCC guidelines](guidelines.html) seem too
@@ -823,8 +879,8 @@ This is one of the reasons why the [IOCCC rules](rules.html) and
Entries are judged by Leonid A. Broukhis and Landon Curt Noll.
-Each entry submitted is given a random id number and subdirectory. The
-entry files including, but not limited to prog.c, Makefile (that we
+Each submission submitted is given a random id number and subdirectory. The
+submission files including, but not limited to prog.c, Makefile (that we
form from around your "how to build" information), as well as any
data files that you submit are all placed under their own directory
stored and judged from this directory.
@@ -836,7 +892,7 @@ do not win, we do not know who did not win.
The above process helps keep us biased for/against any one particular
individual. Therefore you **MUST** refrain from putting any information
-that reveals your identity in your entry.
+that reveals your identity in your submission.
Now some people point out that coding style might reveal the information
about the others. However we consider this to be simply circumstantial
@@ -848,13 +904,13 @@ Honeyman](http://www.citi.umich.edu/u/honey). The judges are on to this trick
and therefore consider any obfuscated source or data file claiming to be from
Honeyman to not be form Honeyman. This of course creates an interesting paradox
known as the "obfuscated Peter Honeyman paradox". Should Peter Honeyman
-actually submit an obfuscated entry, he alone is excluded from the above, as we
+actually submit an obfuscated submission, he alone is excluded from the above, as we
will likely believe it just another attempt at confusion. This _guideline_ is
known as the "Peter Honeyman is exempt" _guideline_.
BTW: None of the entries claiming to be from Peter Honeyman have ever
won an award. So it is theoretically possible that Peter Honeyman
-did submit an entry in the past. In the past, Peter had denied
+did submit an submission in the past. In the past, Peter had denied
submitting anything to the IOCCC. Perhaps those entries were
submitted by one of his students?
@@ -883,7 +939,7 @@ Judging consists of a number of elimination rounds. During a round,
the collection of entries are divided into two roughly equal piles;
the pile that advances on to the next round, and the pile that does
not. We also re-examine the entries that were eliminated in the
-previous round. Thus, an entry gets at least two readings.
+previous round. Thus, an submission gets at least two readings.
A reading consists of a number of actions:
@@ -906,11 +962,11 @@ miscellaneous tests on the source and binary.
**`|`** This is the very _guideline_ that goes, BING!
Until we reduce the stack of entries down to about 25 entries, entries
-are judged on an individual basis. An entry is set aside because it
+are judged on an individual basis. An submission is set aside because it
does not, in our opinion, meet the standard established by the round.
When the number of entries thins to about 25 entries, we begin to form
award categories. Entries begin to compete with each other for awards.
-An entry will often compete in several categories.
+An submission will often compete in several categories.
The actual award category list will vary depending on the types of entries
we receive. A typical category list might be:
@@ -941,27 +997,27 @@ the final round are definitely better than the ones that do not
make it. The selection of the winners out of the final round, is
less clear cut.
-Sometimes a final round entry is good enough to win, but is beat out
-by a similar, but slightly better entry. For this reason, it is
-sometimes worthwhile to re-enter an improved version of an entry
+Sometimes a final round submission is good enough to win, but is beat out
+by a similar, but slightly better submission. For this reason, it is
+sometimes worthwhile to re-enter an improved version of an submission
that failed to win in a previous year. This assumes, of course,
-that the entry is worth improving in the first place!
+that the submission is worth improving in the first place!
More than one IOCCC judge has been known to bribe another IOCCC judge
-into voting for a winning entry by offering a bit high quality chocolate.
+into voting for a winning submission by offering a bit high quality chocolate.
This technique is highly discouraged for use by non-IOCCC judges.
-More often than not, we select a small entry (usually one line), a
-strange/creative layout entry. We sometimes also select an
-entry that abuses the [IOCCC guidelines](guidelines.html) in an interesting way,
+More often than not, we select a small submission (usually one line), a
+strange/creative layout submission. We sometimes also select an
+submission that abuses the [IOCCC guidelines](guidelines.html) in an interesting way,
or that stretches the content rules that while legal, is
nevertheless goes against the intent of the rules.
-In the end, we traditionally pick one entry as 'best'. Sometimes such
-an entry simply far exceeds any of the other entries. More often, the
+In the end, we traditionally pick one submission as 'best'. Sometimes such
+an submission simply far exceeds any of the other entries. More often, the
'best' is picked because it does well in a number of categories.
-In years past, we renamed the winning entry from prog.c to a
+In years past, we renamed the winning submission from prog.c to a
name related to the submitter(s) names. This is no longer done.
Winning source is called prog.c A compiled binary is called prog.
@@ -969,7 +1025,7 @@ Winning source is called prog.c A compiled binary is called prog.
# ANNOUNCEMENT OF WINNERS:
The judges will toot initial announcement of who won, the name
-of their award, and a very brief description of the winning entry
+of their award, and a very brief description of the winning submission
from the [@IOCCC Mastodon account](https://fosstodon.org/@ioccc). You should
follow us on Mastodon and refresh the page (even if you do follow us) as unless
you are mentioned you will not get a notification.
diff --git a/next/rules.html b/next/rules.html
index 9e418d7b5..1ac0f12ad 100644
--- a/next/rules.html
+++ b/next/rules.html
@@ -382,13 +382,12 @@
-
+repo START: this line starts content from: inc/rules.closed.hdr –>
WARNING: These rules are OUT OF DATE
These rules are a VERY TENTATIVE proposal for the next IOCCC
and are VERY LIKELY to be updated before the next IOCCC.
They are are provided as a very tentative hint at what
MIGHT be used in the next IOCCC.
-Please regard these rules as a historical archive.
The IOCCC is closed
The IOCCC is NOT accepting new submissions at this time. See the IOCCC
winning entries page for the entries that have won the IOCCC in
@@ -434,9 +433,9 @@ 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,
+
| Until the start of this IOCCC, these IOCCC rules,
IOCCC guidelines and iocccsize.c (contained in the mkiocccentry
-toolkit and invoked by the
+repo and invoked by the
mkiocccentry(1) tool) should be considered provisional BETA versions and
may be adjusted AT ANY TIME.
When the IOCCC is open, the submission URL is:
@@ -450,10 +449,10 @@ for important information on how to submit to the IOCCC.
The official IOCCC rules and IOCCC guidelines will be
available on the official IOCCC website on or slightly before
the start of this IOCCC. The mkiocccentry toolkit may be obtained at any time
-at the mkiocccentry toolkit repo.
+at the mkiocccentry repo.
Please recheck on or after the start of this IOCCC to be sure you
are using the correct versions of these items before using the IOCCC
-entry submission URL.
+submission URL.
IOCCC RULES
To help us with the volume of entries, we ask that you follow these rules:
Rule 0
@@ -461,11 +460,11 @@ entry submission URL.
Rule 1
-Your entry must be a complete program.
+Your submission must be a complete program.
Rule 2
-The size rule requires your entry to satisfy BOTH Rule 2a and Rule 2b:
+The size rule requires your submission to satisfy BOTH Rule 2a and Rule 2b:
Rule 2a
@@ -490,9 +489,9 @@ as a command like argument to the iocccsize(1) tool. For example:| 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 tool repo.
+mkiocccentry repo.
| If you use the mkiocccentry(1) tool, which we STRONGLY recommend you use,
-then mkiocccentry(1) will invoke iocccsize(1) before packaging your entry for submission.
+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
@@ -517,18 +516,22 @@ the How to enter FAQ.
Rule 4
-If your entry is selected as a winner, it will be modified as follows:
-Your ‘build’ instructions will be incorporated into a Makefile.
-Your source code will be the file prog.c. The compiled binary
-will be called prog.
+| If your submission is selected as a winner, it may be modified in order
+for into the Makefile structure of the Official IOCCC winner website.
+| For example, your submission’s ‘Makefile’ maybe 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.
Rule 5
-Your entry MUST not modify the content or filename of any part of your
-original entry including, but not limited to prog.c, the Makefile
+
Your submission MUST not modify the content or filename of any part of your
+original submission including, but not limited to prog.c, the Makefile
(that we create from your how to build instructions), as well as any data
files you submit.
-If you entry wishes to modify such content, it MUST first copy the
+
If you submission wishes to modify such content, it MUST first copy the
file to a new filename and then modify that copy.
Rule 6
@@ -545,7 +548,6 @@ file to a new filename and then modify that copy.
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
-See also Rule 18.
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.
@@ -561,7 +563,7 @@ before the close of the contest.
Rule 9
| Each person may submit up to and including 10.000000 entries per contest.
-Each entry must be submitted separately.
+Each submission must be submitted separately.
Rule 10
@@ -577,63 +579,130 @@ them in the remarks file.
Rule 12
-Legal abuse of the rules is somewhat encouraged. An entry that, in
+
Legal abuse of the rules is somewhat encouraged. An submission that, in
the opinion of the judges, violates the rules will be disqualified.
Entries that attempt to abuse the rules MUST try to justify why
-their rule abuse is legal, in the remarks file.
+their rule abuse is legal, in the submission’s remarks.md file.
Rule 13
-Any C source that fails to compile because of unescaped octets with
-the high bit set (octet value >= 128) will 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) will be rejected.
-Please do not put trailing control-M’s on remarks file lines.
+
| 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
-When you submit your entry you must have a valid email address
-that can both send and receive email. The online submission
-method is a two phase process that requires the use of an
-approval code. This code will be emailed to you as part of
-phase 1.
-Entries submitted without a working or valid email address will
-be disqualified.
+| 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.
-After your email address has been confirmed, the submission code will
-be valid for submitting and editing the entry for the lifetime of the
-competition.
-See also How may I submit to the IOCCC? in the
-FAQ.
+| See How may I register for the IOCCC? in the
+FAQ for details.
Rule 16
You are STRONGLY encouraged to submit a previously unpublished AND
-original entry. Submissions that are similar to previous entries are
+original submission. Submissions that are similar to previous entries are
discouraged. As we judge anonymously, submissions that have already
been published may be disqualified.
Rule 17
-| The total size of your submission: the sum of the size of the program,
+
TL;DR Rule 17 - Use mkiocccentry(1)
+| 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 bzip2 compressed tarball.
+| The mkiocccentry repo
+contains IMPORTANT tools such as:
+
+chkentry(1)iocccsize(1)mkiocccentry(1)txzchk(1)
+| The above mentioned tools will help you verify that your submission
+conforms to Rule 17.
+| Each above mentioned tools has a -h that provides command line help. For additional details, see the tool man pages.
+Rule 17 - The COMPLEX details
+| Each submission MUST be in the form of a bzip2 compressed tarball file.
+| The bzip2 compressed tarball filename must be of the form:
+
+- ^submit.” + username + - + slot_num + .[1-9][0-9]{9,}.txz$
+
+where username is the 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), and where + is the concatenation operator,
+| Your bzip2 compressed tarball file MUST contain, at a minimum,
+the following files:
+
+Makefileprog.cremarks.md.info.json.auth.json
+| The .info.json must be valid JSON and pass the chkentry(1) test.
+| The .auth.json must be valid JSON and pass the chkentry(1) test.
+| You submission may have additional files, however basename(1) of 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 Makefile must be a non-empty file in Gnu Makefile form.
+| The remarks.md must be a non-empty file in markdown form. See also Rule 18.
+| The bzip2 compressed tarball file MUST be less than
+or equal 3999971 octets in size.
+| When your submission’s bzip2 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.
-| When your submission is formed into a bzip2 compressed tarball file,
-that file must than or equal 3999971 octets in size.
-| The mkiocccentry toolkit
-(see mkiocccentry(1) and txzchk(1)) will help you verify that your
-submission conforms to this Rule 17.
+| You are HIGHLY ENCOURAGED to use the mkiocccentry(1)
+tool to form your submission’s bzip2 compressed tarball. The
+| You submission may have additional files, however filenames of those additional files MUST:
+
+- be less than 100 characters in length
+- conform to the regular expression:
^[0-9A-Za-z][0-9A-Za-z._+-]*$
+
+| Your entry may have sub-directories, however the sub-directories MUST only
+reside under the submission’s top level directory.
+| The directory names of sub-directories path, MUST:
+
+- Be less than 100 characters in length
+- NOT start with:
/
+- NOT contain a path component of:
.
+- NOT contain a path component of:
..
+- Match the regular expression
^[0-9A-Za-z][0-9A-Za-z._+-]*$.
+
+| The Makefile must be a non-empty file.
+| The remarks.md must be a non-empty file in markdown form. See also Rule 18.
+| The bzip2 compressed tarball file MUST be less than
+or equal 3999971 octets in size.
+| When your submission’s bzip2 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 bzip2 compressed tarball MUST pass the txzchk(1) test.
+| 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.
+| 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 bzip2 compressed tarball.
Rule 18
-The entirety of your entry must be submitted under the following license:
+The entirety of your submission must be submitted under the following license:
| 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.
@@ -641,40 +710,36 @@ you MUST HAVE PERMISSION from the owner(s) to submit their cont
Rule 19
-The remarks file must be written in markdown format. See
+
| The remarks.md file, a required non-empty file, must be written in markdown format. See
the Daring Fireball Markdown: Basics
for more information.
| We currently use pandoc to convert markdown to HTML.
+| Please see our IOCCC markdown 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
+Makefile.example,
+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.
-Use a shell command syntax that is compatible with bash.
+| Your Makefile MUST use a syntax that is compatible with bash. You are ENCOURAGED to use set SHELL= bash in 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.
-Do not assume any particular given value of ${CFLAGS} or other
-commonly used make variables. In other words you MUST specify the CFLAGS
-to use.
-See also the
-Makefile.example
-for help in constructing your Makefile. The mkiocccentry, which can be found
-at the mkiocccentry repo, tries to
-detect if required rules exist in your Makefile.
Rule 21
-Your entry must not create or modify files above the current directory
-with the exception of the /tmp and the /var/tmp directories. Your entry
+
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 submit.
@@ -686,10 +751,10 @@ directory name or filename you submit.
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 entry in an obvious way anywhere
+
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
-for disqualification of your entry.
+for disqualification of your submission.
Yes, Virginia, WE REALLY MEAN IT!
Rule 23
@@ -711,7 +776,8 @@ for disqualification of your entry.
| “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.”
+| “Mr. Jock, TV quiz PhD, bags few lynx.”
+| “abcdefg, hijklmnop, qrstu&v, wxy&z.”
Rule 27
@@ -719,7 +785,7 @@ for disqualification of your entry.
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 MORE INFORMATION:
| For questions or comments about the contest, see Contacting the IOCCC.
| Be sure to review the IOCCC Rules and Guidelines as
diff --git a/next/rules.md b/next/rules.md
index d6f5ee3e0..cbc95e77b 100644
--- a/next/rules.md
+++ b/next/rules.md
@@ -1,4 +1,4 @@
-
+repo START: this line starts content from: inc/rules.closed.hdr -->
# WARNING: These rules are OUT OF DATE
@@ -7,8 +7,6 @@ and are **VERY LIKELY** to be updated before the next IOCCC.
They are are provided as a **very tentative** hint at **what
MIGHT** be used in the next IOCCC.
-Please regard these rules as a historical archive.
-
# The IOCCC is closed
@@ -77,9 +75,9 @@ The goals of the IOCCC:
**`|`** 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 iocccsize.c (contained in the [mkiocccentry
-toolkit](https://github.com/ioccc-src/mkiocccentry) and invoked by the
+repo](https://github.com/ioccc-src/mkiocccentry) and invoked by the
`mkiocccentry(1)` tool) should be considered provisional **BETA** versions and
**may be adjusted _AT ANY TIME_**.
@@ -98,11 +96,11 @@ Please wait to submit your entries until after that time.
The official [IOCCC rules](rules.html) and [IOCCC guidelines](guidelines.html) will be
available on the [official IOCCC website](../index.html) on or slightly before
the start of this IOCCC. The `mkiocccentry` toolkit may be obtained at any time
-at the [mkiocccentry toolkit repo](https://github.com/ioccc-src/mkiocccentry).
+at the [mkiocccentry repo](https://github.com/ioccc-src/mkiocccentry).
Please recheck on or after the start of this IOCCC to be sure you
are using the correct versions of these items before using the IOCCC
-entry submission URL.
+submission URL.
# IOCCC RULES
@@ -119,14 +117,14 @@ We need a rule 0. :-)
## Rule 1
-Your entry must be a complete program.
+Your submission must be a complete program.
## Rule 2
-The size rule requires your entry to satisfy **BOTH** [Rule 2a](#rule2a) and [Rule 2b](#rule2b):
+The size rule requires your submission to satisfy **BOTH** [Rule 2a](#rule2a) and [Rule 2b](#rule2b):
@@ -165,10 +163,10 @@ as a command like argument to the `iocccsize(1)` tool. For example:
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 tool repo](https://github.com/ioccc-src/mkiocccentry).
+[mkiocccentry repo](https://github.com/ioccc-src/mkiocccentry).
**`|`** If you use the `mkiocccentry(1)` tool, which we **STRONGLY recommend you use**,
-then `mkiocccentry(1)` will invoke `iocccsize(1)` before packaging your entry for submission.
+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.
Overriding a [Rule 2b](#rule2b) warning carries a **fair amount of risk** that your submission
@@ -208,24 +206,29 @@ Please wait to submit your entries until after that time.
## Rule 4
-If your entry is selected as a winner, it will be modified as follows:
+**`|`** If your submission is selected as a winner, it may be modified in order
+for into the Makefile structure of the [Official IOCCC winner website](https://www.ioccc.org/index.html).
-Your 'build' instructions will be incorporated into a Makefile.
+**`|`** For example, your submission's 'Makefile' maybe be modified.
-Your source code will be the file **prog.c**. The compiled binary
-will be called **prog**.
+**`|`** 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](#rile5), [Rule 18](#rule18) and [Rule 21](#rule21).
## Rule 5
-Your entry **MUST** not modify the content or filename of any part of your
-original entry including, but not limited to **prog.c**, the **Makefile**
+Your submission **MUST** not modify the content or filename of any part of your
+original submission including, but not limited to **prog.c**, the **Makefile**
(that we create from your how to build instructions), as well as any data
files you submit.
-If you entry wishes to modify such content, it **MUST** first copy the
+If you submission wishes to modify such content, it **MUST** first copy the
file to a new filename and then modify that copy.
@@ -252,8 +255,6 @@ under the following license:
**`|`** **[CC BY-SA 4.0 DEED Attribution-ShareAlike 4.0 International](https://creativecommons.org/licenses/by-sa/4.0/)**
-See also [Rule 18](#rule18).
-
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**.
@@ -279,7 +280,7 @@ before the close of the contest.
**`|`** Each person may submit up to and including 10.000000 entries per contest.
-Each entry must be submitted separately.
+Each submission must be submitted separately.
@@ -304,28 +305,28 @@ them** in the remarks file.
## Rule 12
-Legal abuse of the rules is somewhat encouraged. An entry that, in
+Legal abuse of the rules is somewhat encouraged. An submission that, in
the opinion of the judges, violates the rules will be disqualified.
Entries that attempt to abuse the rules **MUST** try to justify why
-their rule abuse is legal, in the remarks file.
+their rule abuse is legal, in the submission's `remarks.md` file.
## Rule 13
-Any C source that fails to compile because of unescaped octets with
-the high bit set (octet value >= 128) will 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`) will 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 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.
@@ -334,25 +335,14 @@ any control-M at the end of remark file lines.
## Rule 15
-When you submit your entry you must have a valid email address
-that can both send and receive email. The online submission
-method is a two phase process that requires the use of an
-approval code. This code will be emailed to you as part of
-phase 1.
-
-Entries submitted without a working or valid email address will
-be disqualified.
+**`|`** 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.
-After your email address has been confirmed, the submission code will
-be valid for submitting and editing the entry for the lifetime of the
-competition.
-
-See also [How may I submit to the IOCCC?](../faq.html#submit) in the
-[FAQ](../faq.html).
+**`|`** See [How may I register for the IOCCC?](../faq.html#register) in the
+[FAQ](../faq.html) for details.
@@ -360,7 +350,7 @@ See also [How may I submit to the IOCCC?](../faq.html#submit) in the
You are **STRONGLY** encouraged to submit a previously unpublished _AND_
-original entry. Submissions that are similar to previous entries are
+original submission. Submissions that are similar to previous entries are
discouraged. As we judge anonymously, submissions that have already
been published may be disqualified.
@@ -369,23 +359,120 @@ been published may be disqualified.
## Rule 17
-**`|`** The total size of your submission: the sum of the size of the program,
+
+### TL;DR Rule 17 - Use `mkiocccentry(1)`
+
+**`|`** 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 bzip2 compressed tarball.
+
+**`|`** The [mkiocccentry repo](https://github.com/ioccc-src/mkiocccentry)
+contains **IMPORTANT** tools such as:
+
+* `chkentry(1)`
+* `iocccsize(1)`
+* `mkiocccentry(1)`
+* `txzchk(1)`
+
+**`|`** The above mentioned tools will help you verify that your submission
+conforms to [Rule 17](#rule17).
+
+**`|`** Each above mentioned tools has a **`-h`** that provides command line help. For additional details, see the tool man pages.
+
+
+### Rule 17 - The COMPLEX details
+
+**`|`** Each submission **MUST** be in the form of a bzip2 compressed tarball file.
+
+**`|`** The bzip2 compressed tarball filename must be of the form:
+
+* ^submit\." + _username_ + - + _slot_num_ + \.[1-9][0-9]{9,}\.txz$
+
+where _`username`_ is the 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), and where _`+`_ is the concatenation operator,
+
+**`|`** Your bzip2 compressed tarball file **MUST** contain, at a minimum,
+the following files:
+
+* `Makefile`
+* `prog.c`
+* `remarks.md`
+* `.info.json`
+* `.auth.json`
+
+**`|`** The `.info.json` must be valid JSON and pass the `chkentry(1)` test.
+
+**`|`** The `.auth.json` must be valid JSON and pass the `chkentry(1)` test.
+
+**`|`** You submission may have additional files, however `basename(1)` of 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 `Makefile` must be a non-empty file in [Gnu Makefile](https://www.gnu.org/software/make/manual/make.html) form.
+
+**`|`** The `remarks.md` must be a non-empty file in markdown form. See also [Rule 18](#rule18).
+
+**`|`** The bzip2 compressed tarball file **MUST** be less than
+or equal **3999971** octets in size.
+
+**`|`** When your submission's bzip2 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.
-**`|`** When your submission is formed into a bzip2 compressed tarball file,
-that file must than or equal 3999971 octets in size.
+**`|`** You are **HIGHLY ENCOURAGED** to use the `mkiocccentry(1)`
+tool to form your submission's bzip2 compressed tarball. The
-**`|`** The [mkiocccentry toolkit](https://github.com/ioccc-src/mkiocccentry)
-(see `mkiocccentry(1)` and `txzchk(1)`) will help you verify that your
-submission conforms to this [Rule 17](#rule17).
+**`|`** You submission may have additional files, however filenames of those additional files **MUST**:
+
+* be less than **100** characters in length
+* conform to the regular expression: `^[0-9A-Za-z][0-9A-Za-z._+-]*$`
+
+**`|`** Your entry may have sub-directories, however the sub-directories **MUST** only
+reside under the submission's top level directory.
+
+**`|`** The directory names of sub-directories path, **MUST**:
+
+* Be less than **100** characters in length
+* **NOT** start with: **`/`**
+* **NOT** contain a path component of: **`.`**
+* **NOT** contain a path component of: **`..`**
+* Match the regular expression `^[0-9A-Za-z][0-9A-Za-z._+-]*$`.
+
+**`|`** The `Makefile` must be a non-empty file.
+
+**`|`** The `remarks.md` must be a non-empty file in markdown form. See also [Rule 18](#rule18).
+
+**`|`** The bzip2 compressed tarball file **MUST** be less than
+or equal **3999971** octets in size.
+
+**`|`** When your submission's bzip2 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 bzip2 compressed tarball **MUST** pass the `txzchk(1)` test.
+
+**`|`** 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.
+
+**`|`** 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 bzip2 compressed tarball.
## Rule 18
-The entirety of your entry must be submitted under the following license:
+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/)**
@@ -399,12 +486,14 @@ You must not submit anything that cannot be submitted under that license.
## Rule 19
-The remarks file must be written in markdown format. See
+**`|`** 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)
for more information.
**`|`** We currently use [pandoc](https://pandoc.org) to convert markdown to HTML.
+**`|`** Please see our [IOCCC markdown guidelines](../markdown.html) for additional markdown guidance.
+
## Rule 20
@@ -414,6 +503,10 @@ 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
+[Makefile.example](https://github.com/ioccc-src/mkiocccentry/blob/master/Makefile.example),
+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`.
@@ -422,7 +515,7 @@ To invoke the C preprocessor use `${CPP}`.
Do not assume that `.` (the current directory) is in the `$PATH`.
-Use a shell command syntax that is compatible with bash.
+**`|`** Your `Makefile` **MUST** use a syntax that is compatible with bash. You are **ENCOURAGED** to use set `SHELL= bash` in your `Makefile.`
**`|`** Assume that commands commonly found in [Single UNIX
Specification](https://en.wikipedia.org/wiki/Single_UNIX_Specification)
@@ -430,23 +523,13 @@ 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.
-Do not assume any particular given value of `${CFLAGS}` or other
-commonly used make variables. In other words you **MUST** specify the `CFLAGS`
-to use.
-
-See also the
-[Makefile.example](https://github.com/ioccc-src/mkiocccentry/blob/master/Makefile.example)
-for help in constructing your Makefile. The `mkiocccentry`, which can be found
-at the [mkiocccentry repo](https://github.com/ioccc-src/mkiocccentry), tries to
-detect if required rules exist in your Makefile.
-
## Rule 21
-Your entry must not create or modify files above the current directory
-with the exception of the `/tmp` and the `/var/tmp` directories. Your entry
+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 submit.
@@ -464,10 +547,10 @@ 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 entry in an obvious way anywhere
+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
-for disqualification of your entry.
+for disqualification of your submission.
Yes, Virginia, **WE REALLY MEAN IT!**
@@ -502,7 +585,8 @@ Even though 24 is not prime, you should still see [Rule 23](#rule23).
**`|`** "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."
+**`|`** "Mr. Jock, TV quiz PhD, bags few lynx."
+**`|`** "abcdefg, hijklmnop, qrstu&v, wxy&z."
@@ -516,7 +600,7 @@ Even though 24 is not prime, you should still see [Rule 23](#rule23).
## 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. :-)