From 6c49bc8955311934ea3559f32041884c73bbe1cf Mon Sep 17 00:00:00 2001 From: Cody Boone Ferguson <53008573+xexyl@users.noreply.github.com> Date: Sat, 29 Nov 2025 12:03:55 -0800 Subject: [PATCH] Various fixes and updates The links to rules should all be good. This includes in news.html, quick-start.html, next/submit.html, 2024/index.html (it had been modified to refer to next/rules.html instead of 2024/rules.html) as well as the guidelines and rules themselves (under next/). Various typo fixes. I'm afraid there are likely others but I must let others deal with that as I am out of time. Removed FAQ about mastodon push notifications. When I added the FAQ about push notifications for mastodon I was incorrect. The web browser interface suggests it but I never got a push notification even before Apple broke them. There seems to be no way at this time to get them. I note that there was a screenshot in the FAQ but this file still is in the repo possibly. I regenerated the html files but it's possible I forgot to do one at the last minute. --- 2024/README.md | 6 +- 2024/index.html | 8 +- faq.html | 85 +-- faq.md | 85 +-- news.html | 4 +- news.md | 4 +- next/guidelines.html | 1321 +-------------------------------- next/guidelines.md | 1692 +----------------------------------------- next/rules.html | 34 +- next/rules.md | 34 +- next/submit.html | 8 +- next/submit.md | 8 +- quick-start.html | 6 +- quick-start.md | 6 +- 14 files changed, 161 insertions(+), 3140 deletions(-) diff --git a/2024/README.md b/2024/README.md index 6a128c458..da448866c 100644 --- a/2024/README.md +++ b/2024/README.md @@ -77,7 +77,7 @@ become more skilled in the programming in the C language. We were pleased to observe that while the [IOCCC size limit](../faq.html#size_rule_history) increased by about 21%, we received many submissions that were well under the new -[Rule 2 Size](../next/rules.html#rule-2-size) including a fair number of quality +[Rule 2](rules.html#rule2) including a fair number of quality small and medium sized submissions. Half of the **IOCCC28 winners** were less than _2/3 of the size limit_, and 10 of the **IOCCC28 winners** were less than _1/2 of the size limit_! @@ -85,10 +85,10 @@ _1/2 of the size limit_! **IMPORTANT NOTE**: The [IOCCC size limit](../faq.html#size_rule_history) increase for **IOCCC28** was the first size increase in over 10 years. Given the quality of submissions we received that were well under the limit, we do **NOT** expect to change the -[Rule 2 Size](../next/rules.html#rule-2-size) for **at least another 10 years** (and likely longer). +[Rule 2](rules.html#rule2) for **at least another 10 years** (and likely longer). **IMPORTANT HINT**: Only 3 of the 23 **IOCCC28 winners** came close to the [Rule -2 Size](../next/rules.html#rule-2-size). Large code size isn't everything. :-) +2](rules.html#rule2). Large code size isn't everything. :-) Those submitting to future contents should **take a careful note** of that fact. diff --git a/2024/index.html b/2024/index.html index b41981ca2..131505802 100644 --- a/2024/index.html +++ b/2024/index.html @@ -513,16 +513,16 @@ become more skilled in the programming in the C language.
We were pleased to observe that while the IOCCC size limit increased by about 21%, we received many submissions that were well under the new -Rule 2 Size including a fair number of quality +Rule 2 including a fair number of quality small and medium sized submissions. Half of the IOCCC28 winners were less than 2/3 of the size limit, and 10 of the IOCCC28 winners were less than 1/2 of the size limit!
IMPORTANT NOTE: The IOCCC size limit increase for IOCCC28 was the first size increase in over 10 years. Given the quality of submissions we received that were well under the limit, we do NOT expect to change the -Rule 2 Size for at least another 10 years (and likely longer).
-IMPORTANT HINT: Only 3 of the 23 IOCCC28 winners came close to the Rule -2 Size. Large code size isn’t everything. :-) +Rule 2 for at least another 10 years (and likely longer).
+IMPORTANT HINT: Only 3 of the 23 IOCCC28 winners came close to the Rule +2. Large code size isn’t everything. :-) Those submitting to future contents should take a careful note of that fact.
Here are the final versions of the IOCCC rules and guidelines that were in diff --git a/faq.html b/faq.html index 1f9fc8ef2..9342f0d78 100644 --- a/faq.html +++ b/faq.html @@ -493,7 +493,7 @@
.top, .allyear, .year and .path files?Do remember that if your submission requires different filenames, then you
MUST make a COPY of them in your Makefile. See also
-Rule 5 - Integrity.
Jump to: top
If you do need different permissions, then see the FAQ on “file permissions”. Also keep in mind -Rule 4 - Files, -Rule 5 - Integrity, +Rule 4 - Required files, +Rule 5 - Do NOT modify submitted files or filenames or parent +directories, and -Rule 16 - Anonymous.
+Rule 16 - Anonymous judging.The txzchk(1) tool will also verify file/directory permissions (and many other
things) for you, and so will chksubmit(1) (along with other checks on files and
directories in your submission directory, including the two required JSON files,
@@ -1344,7 +1343,7 @@ page.
fnamchk(1) as part of its algorithm. If you use mkiocccentry(1)
there should be no problem but if you were to package things manually it is
possible there could be a problem and this poses a big risk of violating
-Rule 4 - Files
+Rule 4 - Required files
or
Rule 17 - Use mkiocccentry.
The fnamchk(1), which txzchk(1) executes, will verify that the
@@ -1353,7 +1352,7 @@ mismatch in what is in the tarball and the name, txzchk(1) will fla
discrepancy as an error and exit with non-zero.
These checks MUST PASS. If they do not you stand a significant chance of having your submission rejected for violating -Rule 4 - Files +Rule 4 - Required files or Rule 17 - Use mkiocccentry.
mkiocccentry(1) tool uses the v7 format. For instance you might
tar --format=v7 -cJf foo.txz directory
IMPORTANT: where -Rule 4 - Files, +Rule 4 - Required files, and -Rule 17 - Use mkiocccentry. +Rule 17 - Use mkiocccentry and the tools from the latest release of the mkiocccentry repo conflict, the IOCCC judges will use their best judgment which @@ -1422,7 +1421,7 @@ page, for help here and also read our FAQ on “mkiocccentry repo bugs”.
At the risk of stating the obvious: submissions that violate -Rule 4 - Files, +Rule 4 - Required files, or Rule 17 - Use mkiocccentry WILL BE REJECTED, so BE SURE to use the latest release of the @@ -1903,7 +1902,7 @@ of the same theme.
Jump to: top
As entries have been fixed it is entirely possible that some of the entries no
@@ -2120,7 +2119,7 @@ two JSON files, .auth.json and .info.json as well as t
.info.json manifest. (Okay there is an option to skip files but this is for
the judges ONLY; use of this option to validate your submission puts you at
a great risk of violating
-Rule 4 - Files,
+Rule 4 - Required files,
or
Rule 17 - Use mkiocccentry!).
As an example, if your submission directory is @@ -2142,7 +2141,7 @@ FAQ on “.auth.json” and the FAQ on “.info.json” as well as -Rule 4 - Files, +Rule 4 - Required files, and Rule 17 - Use mkiocccentry for more information.
@@ -2424,7 +2423,7 @@ will use it on the submission directory as part of the judging process. is reported invalid bychksubmit(1), or if your submission directory is
reported invalid by chksubmit(1), your submission will almost certainly be
rejected for violating the Rules and in particular
-Rule 4 - Files,
+Rule 4 - Required files,
and
Rule 17 - Use mkiocccentry.
An obvious example where chksubmit(1) would fail to validate .auth.json is if
@@ -2435,7 +2434,7 @@ out of range (see above for list). Two more examples would be if a field is
missing or if an unknown filed is in the file. In these cases (and any others
that must be established as valid by chksubmit(1)) your submission would be
rejected for violating
-Rule 4 - Files,
+Rule 4 - Required files,
and
Rule 17 - Use mkiocccentry
and in particular
@@ -2608,17 +2607,17 @@ validate your filename, or if you have the wrong directory name in the
tarball, this will be flaggd.
rule_2a_size (number)
IMPORTANT: if this violates Rule 2a you stand a great chance of having your submission rejected for violating the Rules!
rule_2b_size (number)
IMPORTANT: if this violates -Rule 2b Next Size +Rule 2b Net Size you stand a great chance of having your submission rejected for violating the Rules!
rule_2a_override (boolean)
true if user overrides warning of
-Rule 2a Gross Size
+Rule 2a - Gross Size
violation, else false.IMPORTANT: if the
-Rule 2a Gross Size
+Rule 2a - Gross Size
calculated size is NOT
violated but this is true then you stand a good chance of having your
submission rejected for violating
@@ -2641,43 +2640,27 @@ submission rejected for violating
rule_2a_mismatch (boolean)
true if
-Rule 2a Gross Size
+Rule 2a - Gross Size
calculated size is not the
same as the file size.rule_2b_override (boolean)
true if user overrides warning of
-Rule 2b Next Size
+Rule 2b - Net Size
violation, else false.IMPORTANT: if the
-Rule 2b Next Size
+Rule 2b - Net Size
calculated size is NOT
violated but this is true then you stand a good chance of having your
submission rejected for violating
Rule 17 - Use mkiocccentry.
highbit_warning (boolean)
true if iocccsize detects a high bit (unescaped octets with the high
-bit set - octet value >= 128); see
-Rule 12 - UTF-8,
-else false.nul_warning (boolean)
true if iocccsize detects a NUL character in the prog.c, else
-false.trigraph_warning (boolean)
true if iocccsize detects an unknown or invalid trigraph in
prog.c, else false.wordbuf_warning (boolean)
ungetc_warning (boolean)
true if prog.c triggered an ungetc(3) error, else false.Jump to: top
-To do this you need to go to the IOCCC mastodon -account with a computer (it is unclear how to do -this with a mobile device, if it is even possible) and then you should see a -bell icon. Make sure it’s activated. If you mouse over it when it’s not enabled -it should look something like this, assuming of course we follow you! :-) (if -not the message about following each other won’t show up):
-
It is not yet clear if this only works on desktop/computers or mobile devices -too as it was only just discovered (31 July 2025) but whatever the case we -suggest you do it.
-Jump to: top
-
-It is not yet clear if this only works on desktop/computers or mobile devices
-too as it was only just discovered (31 July 2025) but whatever the case we
-suggest you do it.
-
-
-Jump to: [top](#)
-
-
The IOCCC Rule 12 - UTF-8 no longer discourages the +
The IOCCC Rule 12 - UTF-8 no longer discourages the
use of UTF-8 in C source. Since the days of -std=gnu17 compilers,
UTF-8 characters do not impose a compiler problem. The related guideline
states that “Rule 13 no longer discourages the use of UTF-8 +characters in C code”.
The IOCCC Rule 8 - Submission wording has been fixed. It no longer +
The IOCCC Rule 8 - Submitting requirements wording has been fixed. It no longer states that email will be sent. Instead it talks about potential slot comment modifications as means to tell the submitter that their submission was received.
All of the import IOCCC dates within the IOCCC rules diff --git a/news.md b/news.md index 8783f9f10..f0c4e1688 100644 --- a/news.md +++ b/news.md @@ -406,12 +406,12 @@ See also the [mkiocccentry FAQ](https://github.com/ioccc-src/mkiocccentry/blob/m ## 2024-12-30 -The IOCCC [Rule 12 - UTF-8](next/rules.html#rule-12---utf-8) no longer discourages the +The IOCCC [Rule 12 - UTF-8](next/rules.html#rule12-utf8) no longer discourages the use of UTF-8 in C source. Since the days of `-std=gnu17` compilers, UTF-8 characters do not impose a compiler problem. The related guideline states that "Rule 13 no longer discourages the use of UTF-8 +characters in C code". -The IOCCC [Rule 8 - Submission](next/rules.html#rule-8---submission) wording has been fixed. It no longer +The IOCCC [Rule 8 - Submitting requirements](next/rules.html#rule8-submitting-requirements) wording has been fixed. It no longer states that email will be sent. Instead it talks about potential slot comment modifications as means to tell the submitter that their submission was received. diff --git a/next/guidelines.html b/next/guidelines.html index 53fb9d128..09d6d2568 100644 --- a/next/guidelines.html +++ b/next/guidelines.html @@ -452,1305 +452,28 @@ -
All Rights Reserved. Permission for personal, education or non-profit use is -granted provided this copyright and notice are included in its entirety -and remains unaltered. All other uses must receive prior permission in -writing by contacting the judges.
-Be sure to read the IOCCC rules.
-Your submission must satisfy BOTH the -Rule 2a Gross Size -AND -Rule 2b Net Size rules.
-To check your code against
-Rule 2 - Size restrictions, use the iocccentry(1) tool.
-Your submission must satisfy BOTH the maximum size Rule 2a Gross Size
-AND the Rule 2b Net Size.
To check your code against Rule 2 - Size, use the iocccentry(1) tool.
-For example:
iocccsize prog.c
-The IOCCC size tool algorithm can be summarized as follows:
---The size tool counts most C reserved words (keyword, secondary, and selected -preprocessor keywords) as 1. The size tool counts all other bytes as 1 -excluding ASCII whitespace, and excluding any ‘
-;’, ‘{’ or ‘}’ followed by -ASCII whitespace, and excluding any ‘;’, ‘{’ or ‘}’ byte immediately -before the end of file.ASCII whitespace includes ASCII tab, ASCII space, ASCII newline, ASCII formfeed, and ASCII carriage return.
-When ‘
-;’, ‘{’ or ‘}’ are within a C string, they may still not be -counted by the IOCCC size tool.
In cases where the above summary and the algorithm implemented by
-the IOCCC size tool iocccsize(1) conflict, the algorithm implemented
-by the minimum required version of iocccsize(1) is preferred by the IOCCC
-judges.
Make sure iocccsize does not flag any issues with your prog.c.
There a much less need to #define C reserved words in an effort
-to get around the size limits of
-Rule 2 - Size restrictions
-because of the iocccsize(1) algorithm.
-by the current version of iocccsize(1) is preferred by the IOCCC judges.
-Make sure iocccsize(1) does not flag any issues with your prog.c.
There a much less need to #define C reserved words in an effort to get
-around the size limits of Rule 2 - Size because of the iocccsize(1) algorithm.
Yes Virginia, the previous guideline sentence is an important hint!
-Jump to: top
-See FAQ on “What is an author handle?”.
-Jump to: top
-While it is NOT required, you are allowed to use tools or services such as:
-The IOCCC has a rich history of remarkable winning entries created by
-authors who skillfully employed various techniques to develop their code.
-If you do make use of such tools or services, then we ENCOURAGE you to
-describe how you used such tools in your remarks.md file.
In short: You created it, you own it, its an original work, or you have explicit permission to the work.
-See FAQ on “May I use AI, LLM, Virtual coding assistants, or similar tools to write my submission?”.
-Jump to: top
-We do realize that there are holes in the IOCCC rules, and invite -submitters to attempt to apply creative rule interpretation. A rule abuse though, even -if not rewarded, may result in a subsequent rule change for future contests.
-We sometime award ‘Best abuse of the rules’ or ‘Worst abuse of the rules’, -or some variation, to a submission that creatively attempts to exploit a holes in the -We sometimes award ‘Best abuse of the rules’ or ‘Worst abuse of the rules’, -or some variation to a submission that creatively attempts to exploit a holes in the -IOCCC rules.
-When we do need to plug a hole in the IOCCC rules -or IOCCC guidelines, we will attempt to use a very small plug, -if not smaller.
-Or, maybe not. :-)
-Legal rule abuse may involve, but is not limited to, doing things that are -technically allowed by the IOCCC rules and yet do not fit the spirit of what -we intended to be submitted.
-Legal abuse of the IOCCC rules is NOT an invitation to violate the -IOCCC rules (especailly Rule 17 - Packaging ). A submission that violates the rules in the -opinion of the IOCCC judges, WILL be -disqualified. RULE ABUSE CARRIES A CERTAIN LEVEL OF RISK! If you -have a 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, making sure to note in the one that does not abuse the rules that this is -another version, so that the judges do not assume you uploaded it by mistake.
-If you intend to abuse the IOCCC rules,
-indicate so in your remarks.md file. You MUST try to justify, plead, beg,
-why you consider your rule abuse to be allowed under the
-IOCCC rules. Humor 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 you have a 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, making sure to note in the one that does not abuse the rules that -this is another version, so that the judges do not assume you uploaded it by -mistake.
-If you do bypass the mkiocccentry(1) warnings about
-Rule 2a - Gross Size
-and/or about
-Rule 2b - Net Size
-Rule 2a Gross Size
-or about
-Rule 2b Net Size
-or any other
-rule and submit a submission anyway, you MUST try to justify why the IOCCC
-IOCCC judges should not reject your submission due to a rule
-violation, and you would be wise to do this towards the top of your remarks.md
-file.
We are often asked why the contest IOCCC rules and IOCCC -guidelines seem strange or contain mistakes, flaws, or -grammatical errors. One reason is that we sometimes make genuine mistakes, but -in many cases such problems, flaws or areas of confusion are deliberate.
-Changes to IOCCC rules and IOCCC guidelines in -response to rule abuses, are done in a minimal fashion. Often we will -deliberately leave behind holes (or introduce new ones) so that future rule -abuse can continue. A clever author should be able to read them and “drive a -truck through the holes” in the IOCCC rules and IOCCC -guidelines.
-At the risk of stating the obvious, this contest is a parody of the software -development process. The IOCCC rules and IOCCC guidelines -are only part of the overall contest. Even so, one might think the -contest IOCCC rules and IOCCC guidelines process as a parody -of the sometimes tragic mismatch between what a customer (or marketing) wants -and what engineering delivers. Real programmers must face obfuscated and -sometimes conflicting, balloning specifications, and requirements from marketing, sales, -product management and even from customers themselves on an all too regular basis. -This is one of the reasons why the IOCCC rules and -IOCCC guidelines are written in obfuscated form.
-Jump to: top
-You may use git, or services such as GitHub
-to develop and maintain your submission. However, we DISLIKE
-submissions that require such services in order to build/compile your submission.
Submissions will be judged in an environment that has no IDE. -Any submission that fails to compile/build because it requires -an IDE will be rejected.
-We will use the GNU make(1) tool, your Makefile, as well as tools found in the
-Single UNIX Specification
-environments, and commonly found on systems that reasonably conform to the
-Single UNIX Specification
-in the building and compiling of your submission.
Your Makefile MUST be compatible with GNU make and we suggest you use
-Makefile.example as a template, renamed as Makefile of
-course.
Jump to: top
-We STRONGLY recommend you do install the most recent release of -mkiocccentry toolkit -As use of using older versions of the mkiocccentry toolkit to are HIGHLY LIKELY to be REJECTED!
-If you submit your own JSON files (other than .auth.json and
-.info.json) then they do NOT have to be valid JSON.
However, if you do provide invalid JSON files, PLEASE
-document and clearly explain this in your remarks.md file.
If you use an optional filename for something other than their intended use -in order to get past the file limit, we will consider that an abuse of rules.
-The mkiocccentry generated tarball does NOT reveal who you are! For this
-reason, the tarball MUST be a v7 format tarball.
You should NOT use a tarball as an extra file for a test-suite unless you
-have a very good reason for this: if you do include a tarball as an extra file,
-then you MUST specify why in your remarks.md file.
If you DO include a tarball an extra file, and the build process or the program extracts
-said tarball(s), the make clobber rule MUST remove the extracted files.
Instead of including a large test-suite that requires a lot of files as part of your submission,
-and your submission doesn’t require the test-suite to be available to run,
-then in your remarks.md a URL where such a test-suite may be downloaded from
-and how to use the test-suite to test your submission.
If you DO include a tarball then make sure it uses the v7 format. See the -FAQ on “extra files” -for details on how to make a v7 tarball.
-See the
-FAQ on “What should I do with the try.sh and try.alt.sh scripts?”.
See the
-FAQ on “What is a .auth.json file?”.
See the
-FAQ on “What is a .info.json file?”.
See the -FAQ on “How can I validate my submission directory?”.
-See the -FAQ on “What permissions may my files be and what if I need different permissions?”.
-See the -FAQ on “What are the detailed recommendations for a submission Makefile?”.
-See the -FAQ on “What are the details behind Rule 17 - Use mkiocccentry?”.
-Jump to: top
-The IOCCC submit server, and related services -use the most recent version of the -mkiocccentry toolkit: -submissions that package using older versions of the -mkiocccentry toolkit -are LIKELY to be REJECTED!
-You REALLY SHOULD use the latest mkiocccentry toolkit -are LIKELY to be REJECTED! So you REALLY SHOULD use the latest mkiocccentry toolkit -to package your own submission.
-The mkiocccentry(1) tool runs a number of checks by way of these
-mkiocccentry toolkit tools:
Do NOT use txzchk(1) or fnamchk(1) command line options that are labeled
-“for TESTING purposes” in their respective man pages.
Do NOT use fnamchk(1) command line options that are labeled “for TESTING purposes”
-in the fnamchk(1) man page.
Do NOT use chkentry(1) command line options that are labeled “for the use by the IOCCC judges only”
-in the chksubmit(1) (or chkentry(1)) man page(s).
-Similarly do NOT use chkentry(1) command line options marked “for the use
-by the IOCCC judges only” in the chkentry(1) man page.
To view mkiocccentry toolkit man pages, -while your current directory is the top of the source tree:
-man soup/man/man1/mkiocccentry.1
-man soup/man/man1/iocccsize.1
-man soup/man/man1/txzchk.1
-man test_ioccc/man/man1/fnamchk.1
-man soup/man/man1/chksubmit.1
-man soup/man/man1/chkentry.1
-The above man(1) commands will show the toolkit man pages without having to install them first.
So that you do not have to repeatedly answer all the mkiocccentry(1) questions,
-use mkiocccentry -a answers ... to create a file containing the answers you first give,
-so later enter mkiocccentry -i answers ... to reuse those same answers.
The mkiocccentry -A answers ... does the same thing except that the answers file will be overwritten.
The mkiocccentry -i answers ... will still be required to confirm “Yes/No” questions.
Use mkiocccentry -Y -i answers .. to force a yes answers with great caution
-because it might force a yes answer to something you do NOT want, such as a
-change in your code that violates a detected rule.
-The mkiocccentry -i answers .. will still be required to confirm “Yes/No” questions.
-While mkiocccentry -Y -i answers .. will force yes answers, use with great caution,
-because it might force a yes answer to something you do NOT want.
To help with not having to repeatedly enter a UUID, put your UUID into a file and use
-mkiocccentry -u uuidfile ..., or use mkiocccentry -U UUID ... to give the UUID
-on the command line.
If you wish to test that your submission passes the mkiocccentry(1) tests
-without having to type in answers each time, you can use the -d or -s seed
-option to mkiocccentry for the tool to pseudo-randomly create answers for you.
-For example:
mkiocccentry -d workdir topdir
-Do NOT submit a tarball formed by mkiocccentry -d .. OR by
-mkiocccentry -s seed .. OR by using the test UUID!
The mkiocccentry(1) tool creates an xz(1) compressed v7 format tarball using a tar(1)
-command of the form:
cd workdir/UUID-slot_num && tar --format=v7 -cJf submit.UUID-slot_num.timestamp.txz UUID-slot_num
-In many places the mkiocccentry(1) tool will prompt you to verify what you input, allowing you to
-correct details as you go along.
Pressing the “enter key” at the mkiocccentry(1) tool prompts will allow you
-to proceed with a default, however make sure the default is the CORRECT
-answer.
The mkiocccentry(1) tool will use code from iocccsize(1) which detects a number of
-issues (such as Rule 2 - Size) that you may ignore,
-however ignoring such issues comes with a significant level of risk!
-issues (such as Rule 2 - Size) that you may ignore,
-however ignoring such issues comes with a significant level of risk as noted else where.
Once the tarball is packaged it will
-run txzchk(1), which will also run fnamchk(1), as part of its algorithm.
The use of mkiocccentry -W .... is highly discouraged as this may ignore
-warnings about a problem that may cause your submission to be REJECTED!”
If mkiocccentry encounters an error, the program will exit and the xz
-compressed tarball will NOT be generated: this is a feature, not a bug!
If you encounter a bug with the
-mkiocccentry toolkit
-PLEASE run the bug_report.sh script to help us out here!
While you don’t have to install the
-mkiocccentry toolkit,
-then in order to run a tool outside the repo directory
-you will have to specify mkiocccentry(1) command line options to locate required tools
-such as chkentry(1) (mkiocccentry -C chkentry ..), txzchk(1) (mkiocccentry -T txzchk ..),
-and fnamchk(1) (mkiocccentry -F fnamchk ..).
The mkiocccentry(1) tool will ignore any filename or directory that begins with a period (.).
The mkiocccentry(1) tool will ignore all files that begin with COPYING, COPYRIGHT, and LICENSE, regardless
-of filename case.
The mkiocccentry(1) tool will reject any of the following files if they are found directly under
-the top level directory (topdir):
[0-9][0-9][0-9][0-9]_*.tar.bz2 file globThe files listed in the above list are allowed to exist in sub-directories: just NOT directly under
-the top level directory (topdir).
The mkiocccentry(1) tool evaluates all filenames and directory names in a case
-independent way: thus FOO, Foo, and foo are considered the SAME file
-even if your filesystem doesn’t do the same.
Having two or more filenames that differ only by case WILL lead to problems -because of the previous statement.
-When the mkiocccentry(1) tool ignores a file, that file is NOT included as
-part of your submission.
When the mkiocccentry(1) tool ignores a directory, that directory,
-and everything under that directory is NOT included as part of
-your submission.
The mkiocccentry(1) tool will ignore all symlinks.
Creating a directory directly under the top level directory (topdir)
-that is normally considered to be a regular file, such as a directory
-named Makefile, prog.alt.c, prog.c, remarks.md, try.alt.sh,
-or try.sh is NOT a good idea and will likely cause the
-mkiocccentry(1) tool to abort with a fatal error.
The required Makefile and remarks.md files may NOT be empty. This
-does not mean just 0 bytes but also that it MUST have content, and
-content that is relevant (e.g. a Makefile with just comments is NOT
-allowed). However, with the exception of the Makefile, the mkiocccentry(1)
-tool will ONLY check file size.
If the optional file try.alt.sh, or try.sh exists and is an empty file,
-the mkiocccentry(1) tool will abort with a fatal error.
If the mkiocccentry(1) tool encounters anything that isn’t a file, isn’t a
-directory, and isn’t a symlink (which the tool ignores), the mkiocccentry(1)
-tool to abort with a fatal error.
See
-FAQ on “How do I report bugs in an mkiocccentry tool?”.
See Rule 11 - Legal rule abuse for warnings about ignoring mkiocccentry(1) tool warnings.
See
-FAQ on “What is the fnamchk tool?”.
See -FAQ on “What is mkiocccentry in simple terms?”.
-See -FAQ on “What is the mkiocccentry tool, how do I obtain it and how do I use it”.
-Jump to: top
- CSTD= -std=c99
- OPT= -O0 -g3
- # Common C compiler warning flags
- #
- CWARN= -Wall -Wextra ${CSILENCE} ${CUNKNOWN}
-
--Weverything option CWARN= -Wall -Wextra -pedantic
-
-
-
-
-All other things being equal, a program that must turn off fewer -warnings will be considered better, for certain values of better.
- - CSILENCE= -Wno-some-thing -Wno-another-thing
-
- CSILENCE= -Wno-parentheses -Wno-binding-in-condition -Wno-misleading-indentation
-
- CUNKNOWN=
-
- CUNKNOWN= -Wno-unknown-warning-option
-
- CDEFINE= -Dfoo -Dbar=baz
-
- CINCLUDE= -include stdio.h
- COTHER= -fno-math-errno
-
-
-These guideline are hints and suggestions, NOT IOCCC rules.
-While submissions that violate guideline are allowed, -submissions that remain within the IOCCC guidelines are preferred.
-You are encouraged to review the following FAQs:
- -While the contest is open, you may modify your -previously uploaded submission by rebuilding your submission with the -mkiocccentry toolkit, -and then re-uploading it to the same slot number on the -submit server.
-The official locale of the IOCCC is C.
-You are encouraged to examine the winners of previous contests.
-Because rules change from year to year, some winning entries -of the past may be rejected this year.
-What was was unique and novel one year might be ‘old’ the next year.
-A submission is usually examined in a number of ways. We typically apply -a number of tests to a submission:
-#include lines#define and #include linesclang-format(1))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 submission need not pass all of the above tests as in certain cases, -a test is not important.
-Submissions that compete for the -‘strangest/most creative source layout’ need not do as well as -others in terms of their algorithm.
-Given two submissions, we are more inclined to pick the submission that -does something interesting when it’s executed.
-IMPORTANT: Be sure that your submission works as documented in your remarks.md file.
We sometimes make an effort to debug a submission -that has a slight problem, particularly in or near the final round. -On the other hand, we have seen some otherwise excellent submissions -fall down because they didn’t work as documented.
-If you submission has bugs and/or mis-features, you are MUCH BETTER off
-documenting such bugs and/or mis-features in your remarks.md file.
Consider an example of a prime number
-printing program that claims that 16 is a prime number.
-Noting such a bug in your remarks.md file could save your submission:
--“this submission sometimes prints the 4th power of a prime by mistake”
-
Sometimes a strange bug or (mis-)feature can even help the submission! Of course, a correctly -working submission might be better.
-We tend to look down on a
-prime number
-printer that claims that 16 is a prime number.
-Clever people will note that 16 might be prime under certain conditions. ;-)
-Wise people, when submitting something clever
-will fully explain such cleverness in their submission’s remarks.md file.
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.
-Consider using misleading or subtle tricks layered on top of or under -an appropriate level of obfuscation.
-A clean looking program with -misleading comments and variable names might be a VERY GOOD START -to a great submission!
-Jump to: top
-We VERY MUCH LIKE submissions that use an edited variant of the
-example Makefile, as described and linked to in the Makefile section,
-renamed as Makefile of course. This makes it easier for the IOCCC judges
-to test your submission. And if your submissions wins, it makes it easier to integrate it into
-the Official IOCCC winner website.
We VERY MUCH LIKE submissions that have some educational value. This does NOT mean
-that your submission should not be obfuscated but rather that the IOCCC has moved away from
-the idea of “spoilers”. You should not encrypt or rot13 content in your remarks.md file.
It is VERY MUCH appreciated if your remarks have some educational -value. And although educational value is not required, it is an -EXCELLENT bonus.
-We LIKE submissions that use an edited version of the
-try.sh example script (and if you have alternate code,
-the same applies with the try.alt.sh script):
Of course, it is quite possible that only one invocation is -possible, so it is not necessarily detrimental to your submission if you do not -include one, though we do like interesting and creative uses of submissions. See -also the -FAQ on “submitting try.sh and try.alt.sh scripts”.
- - - - -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
-as a program that is more well rounded in confusion.
Many C compilers DISLIKE the following code, and so do we:
- #define d define
- #d foo /* <-- don't expect this to turn into #define foo */
-In other words, it is a compilation error, and in order to get older -IOCCC winning entries that did this to compile, we had to update them to not do this.
-When declaring local or global variables, you should declare the type:
- int this_is_fine;
- this_is_not; /* <-- Try to avoid implicit type declarations */
-We tend to like less a submission that requires either
-gcc OR clang. We prefer submissions that can compile
-under BOTH gcc AND clang. Hint!
We RECOMMEND that the compiler flags you use in your
-submission’s Makefile are supported by BOTH gcc AND clang.
We DISLIKE the use of obscure compiler flags, especially
-if gcc and/or clang do not support it. We suggest
-that you not use any really obscure compiler flags if you can help it.
One side effect of the above is that you cannot assume the use -of nested functions such as:
- int main() {
-| void please_dont_submit_this() {
-| printf("The machine that goes BING!!\n");
- }
-| please_dont_submit_this();
- }
-On 2012 July 20, the IOCCC judges rescinded the encouragement of
-nested functions. Such constructions, while interesting and sometimes
-amusing, will have to wait until they are required by a C standard that are
-actually implemented in BOTH gcc AND clang.
We DISLIKE submissions that require the use of -fnested-functions.
If your submission uses functions that have a variable number of
-arguments, be careful. Systems implement va_list in a wide variety
-of ways. Because of this, a number of operations using va_list are
-not portable and must not be used:
va_list variable to/from a va_list variableva_list variable into/from a va_list variableva_list variable to a function expecting a non-va_list argva_list variable to a function expecting a va_list argva_list variablesva_list as a structure or unionIn particular, do not treat va_list variables as if they were a char **.
We DISLIKE the use of varargs.h. Use stdarg.h instead.
We DISLIKE the use of gets(3). Use fgets(3) instead.
We tend to DISLIKE the blatant use of tarballs in an attempt to simply get
-around the extra file number limit. We realize there may be cases where a
-tarball containing a number of extra files may be needed. Such a need for a
-tarball MUST be explained in the remarks.md file.
On 28 January 2007, the Judges rescinded the requirement that the
-# in a C preprocessor directive must be the 1st non-whitespace byte.
The exit(3) function returns void. Some broken systems have exit(3)
-return int; your submission should assume that exit(3) returns a void.
Small programs are best when they are short, obscure and concise. -While such programs are not as complex as other winners, they do -serve a useful purpose: they are often the only program that people -attempt to completely understand. For this reason, we look for -programs that are compact, and are instructional.
-One line programs should be short one line programs: say around 80 to 132 -bytes long. Going well beyond 132 bytes is a bit too long to be called -a one-liner in our vague opinion.
-We tend to DISLIKE programs that:
-index(3)/strchr(3) differences are OK, but
-sockets/streams specific code is likely not to be)remarks.md file)In order to encourage submission portability, we DISLIKE submissions 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 submission.
-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:
- #include <windows.h> /* we DISLIKE this */
-Unless you are cramped for space, or unless you are entering the -‘Best one liner’ category, we suggest that you format your program -in a more creative way than simply forming excessively long lines.
-The Makefile should not be used to try and get around the size limit. It is
-one thing to make use of a several -Ds on the compile line to help out, but it
-is quite another to use many bytes of -Ds in order to try and squeeze the
-source under the size limit.
Your source code, post-pre-processing, should not exceed the size of -Microsoft Windows. :-)
-You should try to restrict commands used in the build file to commands found in -Single UNIX -Specification -environments and systems that conform to the Single UNIX -Specification.
-You may compile and use your own programs. If you do, try to build and execute -from the current directory. This restriction is not a hard and -absolute one. The intent is to ensure that the building of your -program is reasonably portable.
-We prefer programs that are portable across a wide variety of UNIX-like -operating systems (e.g., Linux, GNU Hurd, BSD, UNIX, etc.).
-Don’t forget that the building of your program should be done -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
- ${CC} prog.c -o prog
-However, you can do something cute such as making your program
-do something dumb (or cute) when it is built ‘automatically’, and
-when it is run with a human involved, do something more clever.
-For example, one could put in their Makefile:
prog: prog.c
- ${CC} prog.c -DNON_HUMAN_COMPILE -o prog
- @echo "See remarks section about alternate ways to compile"
-and then include special notes in your remarks.md file for
-alternate / human intervention based building.
We want to get away from source that is simply a compact blob of -bytes. REALLY TRY to be more creative than blob coding. HINT!
-Please do not use things like gzip(1) to get around the size limit.
-Please try to be much more creative.
We really DISLIKE submissions that make blatant use of including -large data files to get around the source code size limit.
-Did we remember to indicate that programs that blatantly use -some complex state machine to do something simple, are boring? -We think we did. :-)
-Given two versions of the same program, one that is a compact blob -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 submission. See the -IOCCC rules -for details (in particular, -Rule 8 - Submitting requirements).
-We suggest that you avoid trying for the ‘smallest self-replicating’ -source. The smallest, a zero byte entry, 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.
-Please note that the C source below, besides lacking in obfuscation, -is NOT the smallest C source file that when compiled and run, dumps core:
- main;
-Unless you specify -fwritable-strings (see COTHER in the example
-Makefile, described in the Makefile section), do not assume this
-sort of code will work:
char *T = "So many primes, so little time!";
- ...
- T[14] = ';'; /* modifying a string requires: -fwritable-strings */
-Even so, one should probably not assume that this is universally accepted.
-Initialized char arrays are OK to write over. For instance, this is OK:
- char b[] = "Is this OK";
- b[9] = 'k'; /* modifying an initialized char array is OK */
-X client submissions should be as portable as possible. Submissions that -adapt to a wide collection of environments will be favored. For -example, don’t depend on a particular type or size of display. -Don’t assume the use of a particular browser. Instead assume a -generic browser that forms to a widely used W3C -standard. -Don’t assume a particular sound sub-system or video driver is installed -in the OS. Instead, make use of a well known and widely available open -source program (one that actually works) to display audio/visual data.
-X client submissions should avoid using X related libraries and -software that are not in wide spread use.
-As of Red Hat RHEL9.0, the X.org server is deprecated. See the -FAQ on “Xorg deprecation”” -for more details. This does not mean that a submission using this will -necessarily be rejected, but it would be better if it can support Wayland in -some way or another.
-We DISLIKE submissions that use proprietary toolkits such as the M*tif,
-Xv*ew, or OpenL*ok toolkits, since not everyone has them. Use an
-open source toolkit that is widely and freely available instead.
X client submissions should try to not to depend on particular items in
-.Xdefaults. If you must do so, be sure to note the required lines
-in the your remarks.md file. They should also not depend on any
-particular window manager.
Try to avoid submissions that play music that some people believe is copyrighted -music.
-While we recognize that UNIX is not a universal operating system, the contest -does have a bias towards such systems. In an effort to expand the scope of the -contest, we phrase our bias to favor the Single UNIX -Specification.
-You are well advised to submit code that conforms to the Single UNIX -Specification Version 4.
-To quote the IOCCC judges:
-We LIKE programs that:
-Some types of programs can’t excel (anti-tm) in some areas. Your -program doesn’t have to excel in all areas, but doing well in several -areas really does help.
-You are better off explaining what your submission does in your
-remarks.md file section rather than leaving it obscure for the
-IOCCC judges as we might miss something and/or be too tired to
-notice.
We freely admit that interesting, creative or humorous comments in
-your remarks.md file help your chances of winning. If you had to
-read so many twisted submissions, you too would enjoy a good laugh or two.
-We think the readers of the contest winners do as well. We do read
-your remarks.md content during the judging process, so it is worth your
-while to write a remarkable remarks.md file.
We DISLIKE C code with trailing control-M’s (\r or \015) that results
-in compilation failures. Some non-UNIX/non-Linux tools such as
-MS Visual C and MS Visual C++ leave trailing control-M’s on lines.
-Users of such tools should strip off such control-M’s before submitting
-their submissions. In some cases tools have a “Save As” option that will
-prevent such trailing control-M’s being added.
One should restrict libcurses to portable features found on both BSD -and Linux curses.
- -Rule 12 - UTF-8 -no longer discourages the use of UTF-8 -characters in C code.
-It is a very good idea to, in your remarks.md file, tell us why you
-think your submission is obfuscated. This is particularly true if
-your submission has some very subtle obfuscations that we might
-otherwise overlook. <<– Hint!
Anyone can format their code into a dense blob. A really clever -author will try format their submission using a “normal” formatting style -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.md where you talk
-about why you think your submission is obfuscated. On the other hand,
-if you are pushing up against the size limits, you may be forced
-into creating a dense blob. Such are the trade-offs that obfuscators face!
We prefer code that can run on either a 64-bit or 32-bit -processor. However, it is UNWISE to assume it will run on an -some Intel-like x86 architecture**.
-While programs that only run in a specific word size are OK, if you have -to pick, choose a 64-bit word size.
-If your submission MUST run only on a 64-bit or 32-bit architecture,
-then you MUST specify the -arch on your command line
-(see ARCH in the example
-Makefile, described in Makefile section). Do not assume a
-processor word size without specifying -arch. For example:
ARCH= -m64
-Note, however, that some platforms will not necessarily support some
-architectures. For instance, more recent versions of macOS do NOT support
-32-bit!
If there are limitations in your submission, you are highly encouraged
-to note such limitations in your remarks.md file. For example if your
-submission factors values up to a certain size, you might want to state:
--This submission factors values up
-2305567963945518424753102147331756070. -Attempting to factor larger values will produce unpredictable results.
The IOCCC judges might try to factor the value -5, so you want to might state:
---This submission factors positive values up -
-2305567963945518424753102147331756070. Attempting to factor large values will -produce unpredictable results.
However the IOCCC judges might try to also factor 0, so you want to might state:
---This submission factors values between 1 and -
-2305567963945518424753102147331756070. Attempting to factor values outside -that range will produce unpredictable results.
Moreover they might try to also factor 3.5 or 0x7, or Fred, so you want to might state:
---This submission factors integers between 1 and -
-2305567963945518424753102147331756070. Attempting to factor anything else -will produce unpredictable results.
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 submission factors integers between 1 and
-2305567963945518424753102147331756070. -Attempting to factor anything else will cause the program to insult your pet fish Eric.
The IOCCC judges might not have a pet fish named Eric, so you might want to state:
---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, a submission with fewer limitations will be judged -better than a submission with lots of limitations. So you might want to code accordingly -and state:
---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.
-
We DISLIKE the use of ASCII tab characters in markdown files, such as in the required remarks.md file.
We don’t mind the use of 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 annoy us when it comes time to -rendering your markdown content as it complicates the process.
-If you do use ASCII tab characters in your non-markdown files, be -aware that some people may use a tab stop that is different than the common 8 -character tab stop.
-PLEASE observe our IOCCC markdown guidelines
-when forming your submission’s remarks.md file. And if your submission
-contains additional markdown files, please follow those same guidelines for
-those files. See also
-Rule 4 - Required files,
-and the
-FAQ on “markdown”.
We LIKE reading remarks.md files, especially if they contain
-useful, informative, and even humorous content about your submission. Yes, this
-is a hint. :-)
We RECOMMEND you put a reasonable amount effort into the content of the
-remarks.md file: it is a required file for a reason. :-)
Try to be even more creative!
-Jump to: top
-The reason for the times of day are so that key IOCCC events are calculated -to be a functional UTC time. :-)
-At least 2 of several reasons for selecting the prime, 2503, for -Rule 2b - Net Size -may be found on the “Curios!” about 2503.
-The 2503 value for Rule 2b - Net Size is a decimal anagram -of the number of the kernel disk pack of one of the judge’s BESM-6.
-There may or may not be fewer than 2^7+1 reasons why these IOCCC -guidelines seem obfuscated.
-Excessively “dotty” use of the chksubmit(1) or chkentry(1) commands suggests that
-either you like silly things, or that you”RTFS” with some level of care.
Some people might question what actually constitutes a valid JSON file, given -the state of the “so-called” JSON spec.. :-)
-We prefer programs that do not require a fish license: crayons and -cat detector vans not withstanding.
- -While those who are used to temperatures found on dwarf -planets -(yes Virginia, dwarf planets ARE planets!), such as -Pluto, might be able to -explain to the Walrus why our seas are boiling hot, the question of -whether pigs have wings is likely to remain a debatable point to most.
-At least one judge prefers to maintain the use of the -leap-second -as part of the world’s time standard. If your code prints time -with seconds, we prefer that your code be capable of printing the -time of day during a leap-second where the value in seconds -after the minute mark is 60.
-Other windows, on the other hand, might be OK: especially where “X -marks the spot”. Yet on the third hand, windows are best when they are -“unseen” (i.e., not dirty). :-)
-The IOCCC judges, as a group, have a history giving wide degree of latitude -to reasonable submissions. And recently they have had as much longitudinal -variation as it is possible to have on Earth. :-) -Other windows, on the other hand, might be OK: especially where “X -marks the spot”. Yet on the third hand, windows are best when they are -“unseen” (i.e., not dirty). :-)
-The IOCCC judges, as a group, have a history giving wide degree of latitude -to reasonable submissions. And recently they have had as much longitudinal -variation as it is possible to have on Earth. :-)
---You are in a maze of twisty guidelines, all different.
-
There are at least zero IOCCC judges who think that -Fideism has little -or nothing to do with the IOCCC judging process.
--- -All generalizations are false, including this one. – Mark Twain
-
This could be the only guideline that contains the word -fizzbin.
-However, do you know how to play fizzbin? -You do?!? (Except on Tuesday?)
-OK, there are actually 2 guidelines that contain the word -fizzbin, -unless you count this one, in which case there are 3. :-)
-NOTE: The previous guideline in this spot has been replaced by this guideline:
--- -You very well might not be completely prohibited from failing to not partly -misunderstand this particular guideline, but of course, we could not possibly -comment! :-) Nevertheless, you are neither prohibited, nor are you fully or partly -required to determine that this or the previous sentence is either false and/or -perhaps misleading. Therefore, it might be wise for you to not fail to consider -to not do so, accordingly. Thank you very much (allegedly).
-
Any complaints about the above guideline could be addressed to the -Speaker of the House of Commons, or to the speaker of your national -parliament should you have one.
- -We believe that Mark Twain’s quote:
---Get your facts first, then you can distort them as you please.
-
… is a good motto for those writing code for the IOCCC.
- - -If the IOCCC judges are feeling ornery we -might choose to compile your program for running on an Arduino or -a PDP-11. Heck, should we ever find an emulator of 60-bit CDC Cyber -CPU, we might just try your submission on that emulator as well :-)
-Do not fear if you’re not 100% sure of the significance of
-2305567963945518424753102147331756070 as it is not of prime importance: or is
-it? :-)
Jump to: top
-For questions or comments about the contest, see Contacting the IOCCC.
-Be SURE to review the IOCCC Rules and Guidelines as they -may (and often do) change from year to year.
-PLEASE be sure you have the current IOCCC rules and -IOCCC guidelines prior to submitting to the contest.
-See the Official IOCCC website news for additional information.
-For the updates and breaking IOCCC news, you are encouraged to follow -the IOCCC on Mastodon. See our -FAQ on “Mastodon” -for more information. Please do note that unless -you are mentioned by us you will NOT get a notification from the app so you -should refresh the page even if you do follow us.
-Check out the Official IOCCC winner website in general.
-Consider joining the IOCCC discord community via this link: -https://discord.gg/Wa42Qujwnw
-See the -FAQs on “obtaining, compiling, installing and using the mkiocccentry tools” -and the -FAQ on “how to enter the IOCCC” -as that FAQ has important details on -how to register -as well as -how to upload your submission for the IOCCC.
-Jump to: top -
+ +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 the past.
+These guidelines are a TENTATIVE proposal for the next IOCCC +and are likely be to be updated before the next IOCCC.
+See our +FAQ on “rules, guidelines, tools feedback” +as well as our +FAQ on “about asking questions” +about these guidelines. You might also find the FAQ in general useful, especially the +FAQ on “how to enter the IOCCC”.
+Watch both the IOCCC status page and the +@IOCCC mastodon feed for information about +future IOCCC openings.
+HINT to mastodon users: You may wish to refresh the @IOCCC +mastodon feed page and/or mastodon +app from time to time to view IOCCC mastodon updates.
+ + + diff --git a/next/guidelines.md b/next/guidelines.md index 943308171..c6308c625 100644 --- a/next/guidelines.md +++ b/next/guidelines.md @@ -1,1678 +1,28 @@ + -# 29th International Obfuscated C Code Contest Official Guidelines +# The IOCCC is closed - +The IOCCC is **NOT** accepting new submissions at this time. See the +[IOCCC winning entries page](../years.html) for the entries that have won the +IOCCC in the past. -All Rights Reserved. Permission for personal, education or non-profit use is -granted provided this copyright and notice are included in its entirety -and remains unaltered. All other uses must receive prior permission in -writing by [contacting the judges](../contact.html). +These guidelines are a **TENTATIVE proposal** for the next IOCCC +and are **likely be to be updated** before the next IOCCC. +See our +FAQ on "[rules, guidelines, tools feedback](../faq.html#feedback)" +as well as our +FAQ on "[about asking questions](../faq.html#question)" +about these guidelines. You might also find the FAQ in general useful, especially the +FAQ on "[how to enter the IOCCC](../quick-start.html#enter)". -# Guidelines Version +Watch both [the IOCCC status page](../status.html) and the +[@IOCCC mastodon feed](https://fosstodon.org/@ioccc) for information about +future IOCCC openings. - +**HINT to mastodon users**: You may wish to refresh the [@IOCCC +mastodon feed](https://fosstodon.org/@ioccc) page and/or mastodon +app from time to time to view IOCCC mastodon updates. - - - - -Be sure to read the [IOCCC rules](rules.html). - - -These rules are a TENTATIVE proposal for the next IOCCC and are likely be to be updated before the next IOCCC.
See our -FAQ on “rules, guidelines and tools feedback” +FAQ on “rules, guidelines, tools feedback” as well as our -FAQ on “asking questions” +FAQ on “about asking questions” about these rules. You might also find the FAQ in general useful, especially the FAQ on “how to enter the IOCCC”.
Watch both the IOCCC status page and the @@ -503,10 +503,12 @@ of the above dates and times may change AT ANY TIME!
Rule 2 requires that your submission satisfy BOTH
Rule 2a (Gross Size)
and
@@ -516,9 +518,11 @@ During development this can be checked using iocccsize(1):
See the Guidelines for Rule 2 - Size restrictions.
The overall maximum size of your prog.c program source MUST NOT
exceed 4993 bytes.
NOTE: by default iocccsize will only report the rule 2b size, unless the
@@ -526,9 +530,11 @@ code surpasses the limit.
See Entering the IOCCC: the bare minimum you need to know.
When the filename of your program source (i.e., prog.c) 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 MUST
@@ -615,7 +621,8 @@ a case insensitive filesystem.
See the FAQ on “What permissions may my files be and what if I need different permissions?”.
See the Guidelines on the mkiocccentry toolkit.
-See the Guidelines on the Makefile.
+See the +FAQ on “What are the detailed recommendations for a submission Makefile?”.
Do NOT register more than one account!
See Rule 3 - Registering for the IOCCC, -Rule 15 - GNU Makefile compatibility, +Rule 15 - GNU Makefile, and -Rule 17 - Use mkiocccentry.
+Rule 17 - Use mkiocccentry.NOTE: it is better and more portable to NOT modify the ${CC} variable
in the Makefile.
See Rule 15 - GNU Makefile compatibility.
+prog.c<
or remarks.md files, but instead end lines with Unix newline (line-feed,
CTRL+J, \n).
You are permitted, in order to try and squeeze your prog.c under a
-Rule 2a Gross Size and/or
-Rule 2b Net Size
+Rule 2a Gross Size and/or
+Rule 2b Net Size
limits, to NOT end source with a newline. If you
need to do this, please document that in your remarks.md file and if
your compiler complains about this, document this too and update your
@@ -793,8 +800,9 @@ GNU long name options (such as --example) or extensions like
Do NOT assume that . (current directory) is in the $PATH environment
variable.
-See FAQ on “What are the detailed recommendations for a submission Makefile?”.
-See Guidelines for Rule 15 - GNU Makefile compatibility.
+See
+FAQ on “What are the detailed recommendations for a submission Makefile?”.
+See Guidelines for Rule 15 - GNU Makefile.
Rule 16 - Anonymous judging
@@ -842,7 +850,7 @@ the IOCCC judges only”, in their respective man pages.
toolkit command lines that confirm
to the command’s -h “print help message”, again notwithstanding the options
for testing and the IOCCC judges.
-The prog.c file MUST pass the Rule 2 - Size
+
The prog.c file MUST pass the Rule 2 - Size
checks performed by iocccsize(1).
The .auth.json and .info.json files MUST be compatible with what
mkiocccentry(1) generates.
@@ -865,14 +873,14 @@ FAQ on “What is the mkiocccentry tool, how
This 19th rule, while prime, is reserved for future abuse 😁.
Additional rules, both humorous and otherwise, may be added
below this rule in future contests.
-See Rule 6 - Free Rule.
+See Rule 6 - Free Rule.
Further Reading
Please read the Guidelines next for further commentary on these rules.
Read the
Entering the IOCCC: the bare minimum you need to know
for an overview of how to enter the contest.
See also the FAQ.
-And now for something completely different
+And now for something completely different.
Consider joining the IOCCC Discord Server
for discussions about The Rules, questions for the Judges, and C in general.
Leonid A. Broukhis
diff --git a/next/rules.md b/next/rules.md
index 68c519031..f87d14393 100644
--- a/next/rules.md
+++ b/next/rules.md
@@ -10,9 +10,9 @@ These rules are a **TENTATIVE proposal** for the next IOCCC
and are **likely be to be updated** before the next IOCCC.
See our
-FAQ on "[rules, guidelines and tools feedback](../faq.html#feedback)"
+FAQ on "[rules, guidelines, tools feedback](../faq.html#feedback)"
as well as our
-FAQ on "[asking questions](../faq.html#question)"
+FAQ on "[about asking questions](../faq.html#question)"
about these rules. You might also find the FAQ in general useful, especially the
FAQ on "[how to enter the IOCCC](../quick-start.html#enter)".
@@ -78,10 +78,12 @@ Your submission **MUST** be a C program that does NOT `#include` data files.
+
## Rule 2 - Size restrictions
+
`Rule 2` requires that your submission satisfy **BOTH**
[Rule 2a (Gross Size)](rules.html#rule2a)
@@ -98,9 +100,11 @@ See the [Guidelines for Rule 2 - Size restrictions](guidelines.html#guideline-2-
+
### Rule 2a - Gross Size
+
The overall maximum size of your `prog.c` program source **MUST NOT**
exceed **4993** bytes.
@@ -113,9 +117,11 @@ See [Entering the IOCCC: the bare minimum you need to know](../quick-start.html#
+
### Rule 2b - Net Size
+
When the filename of your program source (i.e., `prog.c`) is given as a
command line argument to the latest version of the official IOCCC size
@@ -234,7 +240,8 @@ FAQ on "[What permissions may my files be and what if I need different permissio
See the [Guidelines on the mkiocccentry toolkit](guidelines.html#mkiocccentry_toolkit).
-See the [Guidelines on the Makefile](guidelines.html#makefile).
+See the
+FAQ on "[What are the detailed recommendations for a submission Makefile?](../faq.html#makefile_details)".
@@ -321,9 +328,9 @@ Do **NOT** register more than one account!
See
[Rule 3 - Registering for the IOCCC](rules.html#rule3-register),
-[Rule 15 - GNU Makefile compatibility](rules.html#rule15-gnu-makefile),
+[Rule 15 - GNU Makefile](rules.html#rule15-gnu-makefile),
and
-[Rule 17 - Use mkiocccentry](rules.html#rule-17-mkiocccentry).
+[Rule 17 - Use mkiocccentry](rules.html#rule17-mkiocccentry).
@@ -344,7 +351,7 @@ the make command.
**NOTE**: it is better and more portable to **NOT** modify the `${CC}` variable
in the Makefile.
-See [Rule 15 - GNU Makefile compatibility](rules.html#rule-15---building).
+See [Rule 15 - GNU Makefile](rules.html#rule15-gnu-makefile).
@@ -420,8 +427,8 @@ or `remarks.md` files, but instead end lines with Unix newline (line-feed,
CTRL+J, `\n`).
You are permitted, in order to try and squeeze your `prog.c` under a
-[Rule 2a Gross Size](rules.html#rule-2a-gross-size) and/or
-[Rule 2b Net Size](rules.html#rule-2b-net-size)
+[Rule 2a Gross Size](rules.html#rule2a-gross-size) and/or
+[Rule 2b Net Size](rules.html#rule2b-net-size)
limits, to **NOT** end source with a newline. If you
need to do this, please document that in your `remarks.md` file and if
your compiler complains about this, document this too and update your
@@ -480,9 +487,10 @@ variable.
See [Rule 4 - Required files](rules.html#rule4-required-files).
-See FAQ on "[What are the detailed recommendations for a submission Makefile?](../faq.html#makefile_details)".
+See
+FAQ on "[What are the detailed recommendations for a submission Makefile?](../faq.html#makefile_details)".
-See [Guidelines for Rule 15 - GNU Makefile compatibility](guidelines.html#guideline-15---building).
+See [Guidelines for Rule 15 - GNU Makefile](guidelines.html#guideline-15---building).
@@ -549,7 +557,7 @@ toolkit](https://github.com/ioccc-src/mkiocccentry) command lines that confirm
to the command's `-h` "_print help message_", again notwithstanding the options
for testing and the IOCCC judges.
-The `prog.c` file **MUST** pass the [Rule 2 - Size](rules.html#rule-2---size)
+The `prog.c` file **MUST** pass the [Rule 2 - Size](rules.html#rule2-size)
checks performed by `iocccsize(1)`.
The `.auth.json` and `.info.json` files **MUST** be compatible with what
@@ -586,7 +594,7 @@ This 19th rule, while prime, is reserved for future abuse 😁.
Additional rules, both humorous and otherwise, may be added
below this rule in future contests.
-See [Rule 6 - Free Rule](rules.html#rule6-free).
+See [Rule 6 - Free Rule](rules.html#rule6-free-rule).
## Further Reading
@@ -599,7 +607,7 @@ for an overview of how to enter the contest.
See also the [FAQ](../faq.html).
-And now [for something completely different](guidelines.html#fun)
+And now [for something completely different](guidelines.html#fun).
Consider joining the [IOCCC Discord Server](https://discord.com/invite/Wa42Qujwnw)
for discussions about The Rules, questions for the Judges, and `C` in general.
diff --git a/next/submit.html b/next/submit.html
index df14ca71e..b9df6cacf 100644
--- a/next/submit.html
+++ b/next/submit.html
@@ -452,7 +452,7 @@
-Use mkiocccentry to rebuild# How to upload your submission to the IOCCC
+How to upload your submission to the IOCCC
IMPORTANT NOTE: The IOCCC submit server
is only ready for submissions
ONLY WHEN THE CONTEST IS open.
@@ -518,7 +518,7 @@ the file selection step.
the status of the submission
the filename, which will be in the correct format, assuming you used
mkiocccentry(1) which is HIGHLY recommended so that you do not break
-Rule 17 - Packaging!
+Rule 17 - Use mkiocccentry!
the file length, which txzchk(1) will also verify (the file itself and the
tarball listing).
the upload date.
@@ -576,7 +576,7 @@ To see any status updates, you should logout and log back in later.
… or ANY other error then you MUST FIX your submission, repackage your
tarball with mkiocccentry and upload to the same slot again! If you do not fix
this your submission WILL BE REJECTED for violating
-Rule 17 - Packaging!
+Rule 17 - Use mkiocccentry!
If the format test went well, then you will see:
Status: submit file received by the IOCCC judges. Passed both txzchk and chksubmit tests.
@@ -586,7 +586,7 @@ rules or that everything is OK once the tarball is extracted; it simply means
the tests performed by the tools passed. If you find a flaw in a tool and
abuse it and the tests pass then you stand a significant chance of having your
submission rejected for violating
-Rule 17 - Packaging,
+Rule 17 - Use mkiocccentry,
even if the tests passed.
For details on txzchk, see the
FAQ on “txzchk”.
diff --git a/next/submit.md b/next/submit.md
index 60a5cb6b5..59fee0320 100644
--- a/next/submit.md
+++ b/next/submit.md
@@ -1,4 +1,4 @@
-Use mkiocccentry to rebuild# How to upload your submission to the IOCCC
+# How to upload your submission to the IOCCC
**IMPORTANT NOTE**: The [IOCCC submit server](https://submit.ioccc.org)
is only ready for submissions
@@ -87,7 +87,7 @@ And in the slot it will give you important details like:
- the status of the submission
- the filename, which will be in the correct format, assuming you used
`mkiocccentry(1)` which is **HIGHLY** recommended so that you do not break
-[Rule 17 - Packaging](rules.html#rule-17---packaging)!
+[Rule 17 - Use mkiocccentry](rules.html#rule17-mkiocccentry)!
- the file length, which `txzchk(1)` will also verify (the file itself and the
tarball listing).
- the upload date.
@@ -158,7 +158,7 @@ Or:
... or **ANY** other error then you **MUST FIX** your submission, repackage your
tarball with `mkiocccentry` and upload to the same slot again! If you do not fix
this your submission **WILL BE REJECTED** for violating
-[Rule 17 - Packaging](rules.html#rule-17---packaging)!
+[Rule 17 - Use mkiocccentry](rules.html#rule17-mkiocccentry)!
If the format test went well, then you will see:
@@ -169,7 +169,7 @@ rules or that everything is OK once the tarball is extracted; it simply means
the tests performed by the tools passed. If you find a flaw in a tool and
abuse it and the tests pass then you stand a significant chance of having your
submission rejected for violating
-[Rule 17 - Packaging](rules.html#rule-17---packaging),
+[Rule 17 - Use mkiocccentry](rules.html#rule17-mkiocccentry),
even if the tests passed.
For details on `txzchk`, see the
diff --git a/quick-start.html b/quick-start.html
index 2d58ee0e1..d53f3f306 100644
--- a/quick-start.html
+++ b/quick-start.html
@@ -566,13 +566,13 @@ for more info.
NOTE: Please see our IOCCC markdown guide for important information on using markdown in the IOCCC.
If the mkiocccentry tool indicates that there is a problem with your
submission, especially if it identifies a
-Rule 2 - Size,
+Rule 2 - Size restrictions,
or any other rule, related problem, you are strongly encouraged to revise and
correct your entry and then re-run the mkiocccentry tool.
If you choose to risk violating Rules, be sure and explain your reason
for doing so in your remarks.md file.
See also
-Rule 17 - Packaging!
+Rule 17 - Use mkiocccentry!
IMPORTANT NOTE: the tools that require other tools, mkiocccentry(1) and
txzchk(1), will, as of version 2.0.2 2025-03-11, search under $PATH. If
you have an earlier version and you have not installed the tools and run the
@@ -581,7 +581,7 @@ tools to set the path to the required tools.
Do remember to make sure you have the latest vers
chksubmit(1), txzchk(1) and fnamchk(1). And remember to make sure you have
the latest version so you do not violate
-Rule 17 - Packaging.
+Rule 17 - Use mkiocccentry.
See the
FAQ on “obtaining the latest mkiocccentry tools”,
the
diff --git a/quick-start.md b/quick-start.md
index 192fdf4bb..e975c697e 100644
--- a/quick-start.md
+++ b/quick-start.md
@@ -162,7 +162,7 @@ Three files are required to exist in `topdir`:
If the `mkiocccentry` tool indicates that there is a problem with your
submission, especially if it identifies a
-[Rule 2 - Size](next/rules.html#rule-2---size),
+[Rule 2 - Size restrictions](next/rules.html#rule2-size),
or any other [rule](next/rules.html), related problem, you are **strongly** encouraged to revise and
correct your entry and then re-run the `mkiocccentry` tool.
@@ -170,7 +170,7 @@ If you choose to risk violating [Rules](next/rules.html), be sure and explain yo
for doing so in your `remarks.md` file.
See also
-[Rule 17 - Packaging](next/rules.html#rule-17---packaging)!
+[Rule 17 - Use mkiocccentry](next/rules.html#rule17-mkiocccentry)!
**IMPORTANT NOTE**: the tools that require other tools, `mkiocccentry(1)` and
`txzchk(1)`, will, as of version `2.0.2 2025-03-11`, search under `$PATH`. If
@@ -181,7 +181,7 @@ tools to set the path to the required tools.
Do remember to make sure you have the latest vers
`chksubmit(1)`, `txzchk(1)` and `fnamchk(1)`. And remember to make sure you have
the latest version so you do not violate
-[Rule 17 - Packaging](next/rules.html#rule-17---packaging).
+[Rule 17 - Use mkiocccentry](next/rules.html#rule17-mkiocccentry).
See the
FAQ on "[obtaining the latest mkiocccentry tools](faq.html#obtaining_mkiocccentry)",
the