mirror/ioccc
1
0 Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

checkpoint rules & guidelines, FAQ update, draft IOCCC29 dates

Browse Source 
This is a draft edit of the revised IOCCC guidelines for **IOCCC29**.

Due the above, `next/guidelines.md` has undergone a significant update.
The `next/rules.md` and `faq.md` files have been modified accordingly.

The `faq.md` version is now **29.01 2025-11-28**.
The `next/guidelines.md` version is now **29.00 2025-11-28**.
The `next/rules.md` version is now *29.08 2025-11-28**.

Draft **IOCCC29** dates have been added to `rules.md`.

Ran `make quick_www` to perform the above.

TODO: Continue to revise and improve the IOCCC guidelines.

TODO: Fix typos and minor nits in the `next/guidelines.md`.

TODO: Fix typos and minor nits in the `next/rules.md`.
This commit is contained in:
Landon Curt Noll committed 2025-11-29 00:14:31 -08:00
1 parent bf93637eae
commit 698cd8f92b
7 files changed
+2510 -3572
Download Patch File Download Diff File Expand all files Collapse all files

No files matched your search

faq.html
+222 -2
View File
@@ -453,7 +453,7 @@
<!-- BEFORE: 1st line of markdown file: faq.md -->
<h1 id="ioccc-faq-table-of-contents">IOCCC FAQ Table of Contents</h1>
<p>This is FAQ version <strong>28.2.24 2025-11-18</strong>.</p>
<p>This is FAQ version <strong>29.01 2025-11-28</strong>.</p>
<h2 id="entering-the-ioccc-the-bare-minimum-you-need-to-know">0. <a href="#enter_questions">Entering the IOCCC: the bare minimum you need to know</a></h2>
<ul>
<li><strong>Q 0.0</strong>: <a class="normal" href="#enter">How can I enter the IOCCC?</a></li>
@@ -485,6 +485,7 @@
<li><strong>Q 1.9</strong>: <a class="normal" href="#submission_dir">How can I avoid having to move or delete my submission directory for the same workdir?</a></li>
<li><strong>Q 1.10</strong>: <a class="normal" href="#download_submission">Can I download my submission tarball from the submit server?</a></li>
<li><strong>Q 1.11</strong>: <a class="normal" href="#del_submission">Can I delete a submission from the submit server?</a></li>
<li><strong>Q 1.12</strong>: <a class="normal" href="#makefile_details">What are the detailed recommendations for a submission Makefile?</a></li>
</ul>
<h2 id="ioccc-judging-process">2. <a href="#judging_process">IOCCC Judging process</a></h2>
<ul>
@@ -882,6 +883,9 @@ date
<code>Makefile.example</code>
does have other rules like <code>everything</code> and <code>alt</code>, and we encourage you to use
the one linked to above.</p>
<p>See also the
FAQ on “<a href="#makefile_details">detailed Makefile recommendations</a>”
for more details.</p>
<p>Jump to: <a href="#">top</a></p>
<div id="remarks_md">
<div id="remarks">
@@ -1113,7 +1117,7 @@ and the
FAQ on “<a href="#fnamchk">fnamchk</a>”
for more details.</p>
<div id="extra-files">
<h1 id="what-are-extra-files-and-how-may-i-include-additional-files-beyond-the-max-allowed">1.5: What are extra files and how may I include additional files beyond the max allowed?</h1>
<h3 id="q1.5-what-are-extra-files-and-how-may-i-include-additional-files-beyond-the-max-allowed">Q1.5: What are extra files and how may I include additional files beyond the max allowed?</h3>
</div>
<p>Extra files are defined as files that are not the free files (the required files
<code>prog.c</code>, <code>Makefile</code>, <code>remarks.md</code> and the optional <code>try.sh</code>, <code>try.alt.sh</code>,
@@ -1479,6 +1483,222 @@ Makefile</a> to your Makefile and add to the remarks.md:</p>
<p>Please ignore this submission.</p>
</blockquote>
<p>Jump to: <a href="#">top</a></p>
<div id="makefile_details">
<h3 id="q-1.12-what-are-the-detailed-recommendations-for-a-submission-makefile">Q 1.12: What are the detailed recommendations for a submission Makefile?</h3>
</div>
<p>We <strong>recommend</strong> AND <strong>encourage</strong> you to use the example Makefile,
as the starting point for your submission’s required <code>Makefile</code>:</p>
<ul>
<li><a href="https://github.com/ioccc-src/winner/blob/master/next/Makefile.example">view example Makefile</a></li>
<li><a href="Makefile.example" download="Makefile">download example Makefile</a></li>
</ul>
<p>Feel free to modify the <code>Makefile</code> to suit your obfuscation needs.</p>
<p><strong>Please</strong> add a space between the <code>=</code> and the value of variables, in the
<code>Makefile</code>, making sure that the <code>=</code> comes immediately after the name. See the
example <code>Makefile</code> for examples.</p>
<p>The rest of this section and its subsections will assume that you are using some
variant of the example <code>Makefile</code>, again renamed as <code>Makefile</code>.</p>
<p>We suggest that you compile your submission with a commonly available
<code>-std=gnu17</code> (ISO C 2017 with GNU extensions) C compiler, via <code>clang(1)</code>
and/or <code>gcc(1)</code>.</p>
<div id="cflags">
<div id="flags">
<h4 id="default-compiler-flags">Default compiler flags</h4>
</div>
</div>
<p>Unless you <strong>clearly state</strong> otherwise in your <code>remarks.md</code> file, <strong>AND</strong> put in
your submission’s <code>Makefile</code>, we <strong>will</strong> compile using <code>-std=gnu17 -O3</code>!</p>
<p>It <strong>is OK</strong> if you need to require your submission to <strong>NOT be</strong> compiled
using the default <code>-std=gnu17 -O3</code> settings. Simply <strong>explain why</strong>
your submission should NOT be compiled using <code>-std=gnu17 -O3</code> in
your <code>remarks.md</code> file, <strong>AND</strong> adjust your <code>Makefile</code> accordingly.</p>
<p class="leftbar">
You really should <strong>NOT</strong> redefine <code>CC</code> because doing so makes it less portable. &lt;– <strong>Hint!</strong>
</p>
<p>One reason that you might have to change the flags, is that the optimiser is
known to break some programs, but there are certainly other possible valid
reasons. Again, just update the <code>Makefile</code> and explain it in your <code>remarks.md</code>.
See the <a href="#optimiser">optimiser section</a> for details for changing optimiser
flags.</p>
<p>For more fun when it comes to optimisers breaking code, see
<a href="1986/marshall/compilers.html">1986/marshall/compilers.html</a>.</p>
<div id="compilers">
<h4 id="default-compiler">Default compiler</h4>
</div>
<p><strong>IMPORTANT NOTE</strong>: The use of <code>-std=gnu17</code> does <strong>NOT</strong> imply the use of the <code>gcc</code>
compiler! We often start by compiling using the <strong>clang</strong> C compiler instead.</p>
<p><strong>PLEASE NOTE</strong>: in macOS, the compiler <code>gcc</code> found at <code>/usr/bin/gcc</code> is
in truth the <code>clang</code> compiler, as <code>/usr/bin/gcc --version</code> will show!</p>
<div id="cstd">
<div id="standard">
<h4 id="c-standard">C standard</h4>
</div>
</div>
<p>You may change the standard under which your submission is compiled
by modifying the <code>CSTD</code> Makefile variable. For example, to use <code>c99</code> instead:</p>
<pre><code> CSTD= -std=c99</code></pre>
<div id="opt">
<div id="optimization">
<div id="optimisation">
<div id="optimizer">
<div id="optimiser">
<h4 id="default-optimisation-level">Default optimisation level</h4>
</div>
</div>
</div>
</div>
</div>
<p>You may change the level of optimization and compiler debug level
that your submission is compiled with, by modifying the <code>OPT</code> Makefile variable.
For example, to compile without optimization, and to include debug symbols:</p>
<pre><code> OPT= -O0 -g3</code></pre>
<div id="warnings">
<div id="cwarn">
<h4 id="compiler-warnings">Compiler warnings</h4>
</div>
</div>
<p>The default warning flags are set via the <code>CWARN</code> variable, as shown in the
example <code>Makefile</code>:</p>
<pre><code> # Common C compiler warning flags
#
CWARN= -Wall -Wextra ${CSILENCE} ${CUNKNOWN}</code></pre>
<p>For details on <code>CSILENCE</code> and <code>CUNKNOWN</code>, see the <a href="#disabling-warnings">section on disabling
warnings</a>.</p>
<div id="weverything">
<h5 id="the--weverything-option">The <code>-Weverything</code> option</h5>
</div>
<p>We do <strong>NOT</strong> recommend that you put
the use of <code>-Weverything</code> into your submission’s <code>Makefile</code> for the reasons
cited there. This goes even if your version does not trigger a warning as some
other version might!</p>
<p>On the other hand, if <code>${CC}</code> has “<code>clang</code>” in the name, the example <code>Makefile</code> will
automatically enable <code>-Weverything</code>, so you might have to use <code>-Wno-foo</code>
options anyway, as detailed below.</p>
<p>If “<code>clang</code>” is NOT in <code>${CC}</code>, the <code>CWARN</code> variable will not be further
modified.</p>
<p>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 to fret too much.</p>
<p>We <strong>LIKE</strong> code that has a minimum of warnings, especially under the
more strict <code>-Wall -Wextra -pedantic</code> mode:</p>
<pre><code> CWARN= -Wall -Wextra -pedantic</code></pre>
<p>The two previous guidelines might be thought by some as being somewhat
contradictory. Isn’t life, and isn’t trying to satisfy “contradictory customer
requirements” all too often like that? :-) Try to minimize warnings if you
can.</p>
<p>If you manage to produce very few warnings, or perhaps no warnings at
all under the <code>-Wall -Wextra -pedantic</code> mode, then by all means brag about it in
your <code>remarks.md</code> file <strong>AND BE SURE TO TELL US</strong> the OS, OS version, compiler
and compiler version in which you observed this occurring (in case our OS and
compiler produces a different result: so your submission won’t be penalized for
not meeting your claims).</p>
<p>On the other hand, some warnings cannot be disabled and are enabled by compilers
without any warning option specified. These are sometimes inevitable in
obfuscated code and even in some non-obfuscated code, and you should not worry
about this, though it might be worth pointing out.</p>
<p>For instance, some compilers like to warn about use of pointers as arrays, which seems to
be dubious, as it obviously can’t (always) be avoided, being a big part of C, so
you should not worry about this either; this is the warning
<code>-Wunsafe-buffer-usage</code> and the way to disable it is <code>-Wno-unsafe-buffer-usage</code>.</p>
<h4 id="disabling-warnings">Disabling warnings</h4>
<p class="leftbar">
If you do have to disable warnings due to <code>-Weverything</code> automatically being
included, you might wish to state this fact in your <code>remarks.md</code> file.
And even without <code>-Weverything</code> there can be warnings, as noted above.
</p>
<p>If your submission issues lots of warnings but is otherwise
marvelously obfuscated in multiple levels, don’t worry about it. Nevertheless,
be sure that the warnings do not constitute a potential “<strong>show stopper</strong>”
compiler problem. Be sure that compilers such as both <code>gcc</code> and <code>clang</code> won’t
produce a compiler <strong>error</strong> and refuse to compile your code: unless for some
reason that is what you intend to happen in which case document that too in your
<code>remarks.md</code> file. :-)</p>
<p>All other things being equal, a program that must turn off fewer
warnings will be considered better, for certain values of better.</p>
<p>To turn off a compiler warning, in your submission’s <code>Makefile</code>,
try something such as:</p>
<pre><code> CSILENCE= -Wno-some-thing -Wno-another-thing</code></pre>
<p class="leftbar">
For instance:
</p>
<pre><code> CSILENCE= -Wno-parentheses -Wno-binding-in-condition -Wno-misleading-indentation</code></pre>
<div id="macros">
<h4 id="defining-macros-in-the-makefile">Defining macros in the Makefile</h4>
</div>
<p>If you need to define something on the compile line, use
the <code>CDEFINE</code> Makefile variable. For example:</p>
<pre><code> CDEFINE= -Dfoo -Dbar=baz</code></pre>
<p><strong>NOTE</strong>: just because we offer a default way to use the <code>-D</code> option, we still
do not like excess use of <code>-D</code> to get past size limits, especially since you
could use <code>#define</code> in your code instead.</p>
<div id="include">
<h4 id="include-files-in-the-makefile">Include files in the Makefile</h4>
</div>
<p>If you need to include a file (as in <code>#include</code>) on the command line, use the
<code>CINCLUDE</code> Makefile variable. For example:</p>
<pre><code> CINCLUDE= -include stdio.h</code></pre>
<div id="magic">
<h4 id="magic-in-the-makefile">Magic in the Makefile</h4>
</div>
<p>If you need to add other “<strong>magic</strong>” flags to your compile line,
use the <code>COTHER</code> Makefile variable. For example:</p>
<pre><code> COTHER= -fno-math-errno</code></pre>
<p><strong>NOTE</strong>: <strong>We only recommend using “<em>magic</em>” flags if <em>BOTH</em> <code>gcc</code>
<em>and</em> <code>clang</code></strong> support it.</p>
<p>Again, please note that in macOS, <code>/usr/bin/gcc</code> is actually <code>clang</code>!</p>
<div id="clobber">
<h4 id="the-clobber-rule">The clobber rule</h4>
</div>
<p>When <code>make clobber</code> is invoked, we request that submissions be restored
to their original submission state. For example, any temporary files
(<strong>including</strong> the compiled program(s)) created during the build process, or
during execution should be removed by the <code>clobber</code> rule. In other words, the
only things that should be in the directory after running <code>make clobber</code> is what
is in your submission tarball itself.</p>
<p>While people are free to manage their submission under <code>git(1)</code> or even use a
GitHub repo, dot-files and dot-directories such as <code>.git</code> are not allowed in a
submission.</p>
<p>The <code>mkiocccentry(1)</code> tool will ignore dot-files and dot-directories (such as
<code>.vimrc</code>, <code>.bashrc</code>, <code>.git</code> and <code>.github</code>) and not put them in the submission’s
compressed tarball. So while you may use such files and
directories to help develop your submission, they won’t be included when you run
the <code>mkiocccentry(1)</code> tool.</p>
<p>Even if you did manage to get dot files or dot directories in the tarball
somehow, <code>txzchk(1)</code> will flag it as an error. When the judges run <code>txzchk(1)</code>
on the uploaded submission compressed tarball, if anything is wrong, for
instance if you “sneak in” any dot files or dot directories, the submission
<strong>WILL BE REJECTED</strong> for violating
<a href="next/rules.html#rule-17---packaging">Rule 17 - Packaging</a>!</p>
<p>You may use whatever tools you need to develop your submission, including the
use of <code>git(1)</code> or <code>gh(1)</code>, just be sure that your submission code and your
submission Makefile don’t depend on such tools.</p>
<p>Of course if you do use GitHub to work on your submission, you might want to
make the repo private so you don’t reveal who you are. :-)</p>
<p class="leftbar">
In other words, make <strong>SURE</strong> you keep anonymous who submitted the code!
</p>
<p class="leftbar">
Please do <strong>NOT</strong> use these tools to help with the
<code>clobber</code> rule! For instance, do <strong>NOT</strong> use <code>git clean</code>! Not only does this
depend on the user having <code>git(1)</code> but it also does not account for the
submission tarballs. Even worse is when someone does have it in a <code>git(1)</code> repo
it will remove files that are not under <code>git(1)</code> control! Instead, see the
<code>clobber</code> rule in the example Makefile to see how to manage this.
</p>
<p>In other words, for <code>make clobber</code>, do something like:</p>
<pre><code> clobber:
${RM} -f foo bar baz</code></pre>
<p>and <strong>NOT</strong> something like this:</p>
<pre><code> # do NOT do this!
clobber:
-git clean -f # WRONG !!!</code></pre>
<p>And do <strong>NOT</strong> use <code>git</code> for any other <code>Makefile</code> rule either.</p>
<p><strong>NOTE</strong>: <code>mkiocccentry(1)</code> will directly run <code>make clobber</code> in the submission
directory. And although it is not an error if this fails, if it fails because the
Makefile does not have a clobber rule, it will be flagged by <code>mkiocccentry(1)</code>
(you may ignore this but it does put you at a risk of violating the rules).</p>
<p>Jump to: <a href="#">top</a></p>
<hr style="width:50%;text-align:left;margin-left:0">
<hr style="width:50%;text-align:left;margin-left:0">
<div id="judging_process">
faq.md
+342 -3
View File
@@ -1,6 +1,6 @@
# IOCCC FAQ Table of Contents
This is FAQ version **28.2.24 2025-11-18**.
This is FAQ version **29.01 2025-11-28**.
## 0. [Entering the IOCCC: the bare minimum you need to know](#enter_questions)
@@ -31,6 +31,7 @@ This is FAQ version **28.2.24 2025-11-18**.
- **Q 1.9**: <a class="normal" href="#submission_dir">How can I avoid having to move or delete my submission directory for the same workdir?</a>
- **Q 1.10**: <a class="normal" href="#download_submission">Can I download my submission tarball from the submit server?</a>
- **Q 1.11**: <a class="normal" href="#del_submission">Can I delete a submission from the submit server?</a>
- **Q 1.12**: <a class="normal" href="#makefile_details">What are the detailed recommendations for a submission Makefile?</a>
## 2. [IOCCC Judging process](#judging_process)
@@ -416,6 +417,7 @@ first.
Jump to: [top](#)
<div id="SUS">
<div id="platform">
<div id="portability">
@@ -512,6 +514,10 @@ date
does have other rules like `everything` and `alt`, and we encourage you to use
the one linked to above.
See also the
FAQ on "[detailed Makefile recommendations](#makefile_details)"
for more details.
Jump to: [top](#)
@@ -834,7 +840,7 @@ for more details.
<div id="extra-files">
# 1.5: What are extra files and how may I include additional files beyond the max allowed?
### Q1.5: What are extra files and how may I include additional files beyond the max allowed?
</div>
Extra files are defined as files that are not the free files (the required files
@@ -929,6 +935,7 @@ for more details.
Below we will list more details and link to relevant FAQs as well.
Jump to: [top](#)
@@ -1264,6 +1271,7 @@ FAQ on "[the answers file](#answers_file)".
Jump to: [top](#)
<div id="submission_dir">
### Q 1.9: How can I avoid having to move or delete my submission directory for the same workdir?
</div>
@@ -1285,6 +1293,7 @@ specify the path by the `-r rm` option.
Jump to: [top](#)
<div id="download_submission">
### Q 1.10: Can I download my submission tarball from the submit server?
</div>
@@ -1293,8 +1302,10 @@ We do not support this. If you need to verify your submission, then
you can re-upload (while the contest is in open state) and verify the SHA256
checksum listed in the submission slot.
Jump to: [top](#)
<div id="del_submission">
### Q 1.11: Can I delete a submission from the submit server?
</div>
@@ -1304,9 +1315,334 @@ Makefile](next/Makefile.example) to your Makefile and add to the remarks.md:
> Please ignore this submission.
Jump to: [top](#)
<div id="makefile_details">
### Q 1.12: What are the detailed recommendations for a submission Makefile?
</div>
We **recommend** AND **encourage** you to use the example Makefile,
as the starting point for your submission's required `Makefile`:
- [view example Makefile](%%REPO_URL%%/next/Makefile.example)
- <a href="Makefile.example" download="Makefile">download example Makefile</a>
Feel free to modify the `Makefile` to suit your obfuscation needs.
**Please** add a space between the `=` and the value of variables, in the
`Makefile`, making sure that the `=` comes immediately after the name. See the
example `Makefile` for examples.
The rest of this section and its subsections will assume that you are using some
variant of the example `Makefile`, again renamed as `Makefile`.
We suggest that you compile your submission with a commonly available
`-std=gnu17` (ISO C 2017 with GNU extensions) C compiler, via `clang(1)`
and/or `gcc(1)`.
<div id="cflags">
<div id="flags">
#### Default compiler flags
</div>
</div>
Unless you **clearly state** otherwise in your `remarks.md` file, **AND** put in
your submission's `Makefile`, we **will** compile using `-std=gnu17 -O3`!
It **is OK** if you need to require your submission to **NOT be** compiled
using the default `-std=gnu17 -O3` settings. Simply **explain why**
your submission should NOT be compiled using `-std=gnu17 -O3` in
your `remarks.md` file, **AND** adjust your `Makefile` accordingly.
<p class="leftbar">
You really should **NOT** redefine `CC` because doing so makes it less portable. <-- **Hint!**
</p>
One reason that you might have to change the flags, is that the optimiser is
known to break some programs, but there are certainly other possible valid
reasons. Again, just update the `Makefile` and explain it in your `remarks.md`.
See the [optimiser section](#optimiser) for details for changing optimiser
flags.
For more fun when it comes to optimisers breaking code, see
[1986/marshall/compilers.html](1986/marshall/compilers.html).
<div id="compilers">
#### Default compiler
</div>
**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.
**PLEASE NOTE**: in macOS, the compiler `gcc` found at `/usr/bin/gcc` is
in truth the `clang` compiler, as `/usr/bin/gcc --version` will show!
<div id="cstd">
<div id="standard">
#### C standard
</div>
</div>
You may change the standard under which your submission is compiled
by modifying the `CSTD` Makefile variable. For example, to use `c99` instead:
``` <!---make-->
CSTD= -std=c99
```
<div id="opt">
<div id="optimization">
<div id="optimisation">
<div id="optimizer">
<div id="optimiser">
#### Default optimisation level
</div>
</div>
</div>
</div>
</div>
You may change the level of optimization and compiler debug level
that your submission is compiled with, by modifying the `OPT` Makefile variable.
For example, to compile without optimization, and to include debug symbols:
``` <!---make-->
OPT= -O0 -g3
```
<div id="warnings">
<div id="cwarn">
#### Compiler warnings
</div>
</div>
The default warning flags are set via the `CWARN` variable, as shown in the
example `Makefile`:
``` <!---make-->
# Common C compiler warning flags
#
CWARN= -Wall -Wextra ${CSILENCE} ${CUNKNOWN}
```
For details on `CSILENCE` and `CUNKNOWN`, see the [section on disabling
warnings](#disabling-warnings).
<div id="weverything">
##### The `-Weverything` option
</div>
We do **NOT** recommend that you put
the use of `-Weverything` into your submission's `Makefile` for the reasons
cited there. This goes even if your version does not trigger a warning as some
other version might!
On the other hand, if `${CC}` has "`clang`" in the name, the example `Makefile` will
automatically enable `-Weverything`, so you might have to use `-Wno-foo`
options anyway, as detailed below.
If "`clang`" is NOT in `${CC}`, the `CWARN` variable will not be further
modified.
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 to fret too much.
We **LIKE** code that has a minimum of warnings, especially under the
more strict ` -Wall -Wextra -pedantic` mode:
``` <!---make-->
CWARN= -Wall -Wextra -pedantic
```
The two previous guidelines might be thought by some as being somewhat
contradictory. Isn't life, and isn't trying to satisfy "contradictory customer
requirements" all too often like that? :-) Try to minimize warnings if you
can.
If you manage to produce very few warnings, or perhaps no warnings at
all under the `-Wall -Wextra -pedantic` mode, then by all means brag about it in
your `remarks.md` file **AND BE SURE TO TELL US** the OS, OS version, compiler
and compiler version in which you observed this occurring (in case our OS and
compiler produces a different result: so your submission won't be penalized for
not meeting your claims).
On the other hand, some warnings cannot be disabled and are enabled by compilers
without any warning option specified. These are sometimes inevitable in
obfuscated code and even in some non-obfuscated code, and you should not worry
about this, though it might be worth pointing out.
For instance, some compilers like to warn about use of pointers as arrays, which seems to
be dubious, as it obviously can't (always) be avoided, being a big part of C, so
you should not worry about this either; this is the warning
`-Wunsafe-buffer-usage` and the way to disable it is `-Wno-unsafe-buffer-usage`.
<div id="disabling-warnings">
#### Disabling warnings
</div>
<p class="leftbar">
If you do have to disable warnings due to `-Weverything` automatically being
included, you might wish to state this fact in your `remarks.md` file.
And even without `-Weverything` there can be warnings, as noted above.
</p>
If your submission issues lots of warnings but is otherwise
marvelously obfuscated in multiple levels, don't worry about it. Nevertheless,
be sure that the warnings do not constitute a potential "**show stopper**"
compiler problem. Be sure that compilers such as both `gcc` and `clang` won't
produce a compiler **error** and refuse to compile your code: unless for some
reason that is what you intend to happen in which case document that too in your
`remarks.md` file. :-)
All other things being equal, a program that must turn off fewer
warnings will be considered better, for certain values of better.
To turn off a compiler warning, in your submission's `Makefile`,
try something such as:
``` <!---make-->
CSILENCE= -Wno-some-thing -Wno-another-thing
```
<p class="leftbar">
For instance:
</p>
``` <!---make-->
CSILENCE= -Wno-parentheses -Wno-binding-in-condition -Wno-misleading-indentation
```
<div id="macros">
#### Defining macros in the Makefile
</div>
If you need to define something on the compile line, use
the `CDEFINE` Makefile variable. For example:
``` <!---make-->
CDEFINE= -Dfoo -Dbar=baz
```
**NOTE**: just because we offer a default way to use the `-D` option, we still
do not like excess use of `-D` to get past size limits, especially since you
could use `#define` in your code instead.
<div id="include">
#### Include files in the Makefile
</div>
If you need to include a file (as in `#include`) on the command line, use the
`CINCLUDE` Makefile variable. For example:
``` <!---make-->
CINCLUDE= -include stdio.h
```
<div id="magic">
#### Magic in the Makefile
</div>
If you need to add other "**magic**" flags to your compile line,
use the `COTHER` Makefile variable. For example:
``` <!---make-->
COTHER= -fno-math-errno
```
**NOTE**: **We only recommend using "_magic_" flags if _BOTH_ `gcc`
_and_ `clang`** support it.
Again, please note that in macOS, `/usr/bin/gcc` is actually `clang`!
<div id="clobber">
#### The clobber rule
</div>
When `make clobber` is invoked, we request that submissions be restored
to their original submission state. For example, any temporary files
(**including** the compiled program(s)) created during the build process, or
during execution should be removed by the `clobber` rule. In other words, the
only things that should be in the directory after running `make clobber` is what
is in your submission tarball itself.
While people are free to manage their submission under `git(1)` or even use a
GitHub repo, dot-files and dot-directories such as `.git` are not allowed in a
submission.
The `mkiocccentry(1)` tool will ignore dot-files and dot-directories (such as
`.vimrc`, `.bashrc`, `.git` and `.github`) and not put them in the submission's
compressed tarball. So while you may use such files and
directories to help develop your submission, they won't be included when you run
the `mkiocccentry(1)` tool.
Even if you did manage to get dot files or dot directories in the tarball
somehow, `txzchk(1)` will flag it as an error. When the judges run `txzchk(1)`
on the uploaded submission compressed tarball, if anything is wrong, for
instance if you "sneak in" any dot files or dot directories, the submission
**WILL BE REJECTED** for violating
[Rule 17 - Packaging](next/rules.html#rule-17---packaging)!
You may use whatever tools you need to develop your submission, including the
use of `git(1)` or `gh(1)`, just be sure that your submission code and your
submission Makefile don't depend on such tools.
Of course if you do use GitHub to work on your submission, you might want to
make the repo private so you don't reveal who you are. :-)
<p class="leftbar">
In other words, make **SURE** you keep anonymous who submitted the code!
</p>
<p class="leftbar">
Please do **NOT** use these tools to help with the
`clobber` rule! For instance, do **NOT** use `git clean`! Not only does this
depend on the user having `git(1)` but it also does not account for the
submission tarballs. Even worse is when someone does have it in a `git(1)` repo
it will remove files that are not under `git(1)` control! Instead, see the
`clobber` rule in the example Makefile to see how to manage this.
</p>
In other words, for `make clobber`, do something like:
``` <!---makefile-->
clobber:
${RM} -f foo bar baz
```
and **NOT** something like this:
``` <!---makefile-->
# do NOT do this!
clobber:
-git clean -f # WRONG !!!
```
And do **NOT** use `git` for any other `Makefile` rule either.
**NOTE**: `mkiocccentry(1)` will directly run `make clobber` in the submission
directory. And although it is not an error if this fails, if it fails because the
Makefile does not have a clobber rule, it will be flagged by `mkiocccentry(1)`
(you may ignore this but it does put you at a risk of violating the rules).
Jump to: [top](#)
<hr style="width:50%;text-align:left;margin-left:0">
<hr style="width:50%;text-align:left;margin-left:0">
@@ -1914,6 +2250,7 @@ of `chkentry(1)` when validating a directory; `chkentry(1)` is for the judges
and is what was used in IOCCC28. For IOCCC29 and beyond, `mkiocccentry(1)` uses
`chksubmit(1)` and so should you.
Jump to: [top](#)
@@ -7059,6 +7396,7 @@ to help ensure that everyone may enjoy the IOCCC.
Jump to: [top](#)
<div id="try_mastodon">
### Q 10.6: What is Mastodon and why does the IOCCC use it?
</div>
@@ -7095,6 +7433,7 @@ follow posts something so you will have to check the IOCCC feed manually.
mastodon feed](https://fosstodon.org/@ioccc) page and/or mastodon
app from time to time to view IOCCC mastodon updates.
Jump to: [top](#)
@@ -7117,8 +7456,8 @@ 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](#)
Jump to: [top](#)
<div id="tabstops">
next/guidelines.html
+790 -1519
View File
File diff suppressed because it is too large. Load diff
next/guidelines.md
+1029 -1968
View File
File diff suppressed because it is too large. Load diff
next/rules.html
+49 -35
View File
@@ -480,16 +480,22 @@ granted provided this copyright and notice are included in its entirety
and remains unaltered. All other uses <strong>MUST</strong> receive prior permission in
writing by <a href="../contact.html">contacting the judges</a>.</p>
<h2 id="rules-version">Rules Version</h2>
<p>These IOCCC Rules are version <strong>29.05 2025-11-21</strong>.</p>
<p>These IOCCC Rules are version <strong>29.08 2025-11-28</strong>.</p>
<p>Be sure to read the <a href="guidelines.html">IOCCC guidelines</a>.</p>
<div id="rule0">
<h2 id="rule-0---dates">Rule 0 - Dates</h2>
</div>
<p>This IOCCC runs from ${START_DATE_TIME} UTC to ${CLOSE_DATE_TIME} UTC.</p>
<p>This contest will enter the open state on ${OPEN_DATE_TIME} UTC.</p>
<p>This contest will enter the judging state on ${JUDGMENT_DATE_TIME} UTC.</p>
<p>The above dates are subject to change until the contest is officially open.</p>
<p><strong>NOTE</strong>: As of this draft, the above dates are TBD (to be determined).</p>
<p>This IOCCC runs from <strong>2025-12-03 20:25:12.045045 UTC</strong> to <strong>2026-03-13 17:19:23.293137 UTC</strong>.</p>
<p>This contest will enter the <strong>pending state</strong> on <strong>2025-12-03 20:25:12.045045 UTC</strong>,
allowing people to register for the IOCCC.</p>
<p>This contest will enter the <strong>open state</strong> on <strong>2025-12-15 18:21:24.273033 UTC</strong>,
allowing people to upload submissions to the <a href="https://submit.ioccc.org">IOCCC submit server</a>.</p>
<p>This contest will enter the <strong>judging state</strong> on <strong>2026-03-13 17:19:23.293137 UTC</strong>,
when people will no longer be allowed to upload submissions.</p>
<p>Until the contest enters the <strong>open</strong> state, any or all
of the above <strong>dates and times may change <em>AT ANY TIME</em></strong>!</p>
<p>The above timestamps are in “<em>YYYY-MM-DD HH:MM:SS.micros UTC</em>” format.</p>
<p>See <a href="../status.html">Current status of the IOCCC</a>.</p>
<div id="rule1">
<h2 id="rule-1---program">Rule 1 - Program</h2>
</div>
@@ -503,11 +509,13 @@ and
<a href="rules.html#rule-2b-net-size">Rule 2b Next Size</a>.
During development this can be checked using <code>iocccsize(1)</code>:</p>
<p>iocccsize prog.c</p>
<p>See <a href="guidelines.html#guideline-2---size">Guidelines for Rule 2 - Size</a>.</p>
<div id="rule2a">
<h3 id="rule-2a---gross-size">Rule 2a - Gross Size</h3>
</div>
<p>The overall maximum size of your <code>prog.c</code> program source <strong>MUST NOT</strong>
exceed <strong>4993</strong> bytes.</p>
<p>See <a href="../quick-start.html#enter">Entering the IOCCC: the bare minimum you need to know</a>.</p>
<div id="rule2b">
<h3 id="rule-2b---net-size">Rule 2b - Net Size</h3>
</div>
@@ -531,6 +539,7 @@ to register! The judges are <strong>NOT</strong> responsible for delayed or lost
email or for those who wait until the last minute to try to register!</p>
<p>See <a href="../quick-start.html#enter">Entering the IOCCC: the bare minimum you need to know</a>.</p>
<p>See <a href="rules.html#rule-8---submission">Rule 8 - Submission</a>.</p>
<p>See <a href="guidelines.html#guideline-3---register">Guidelines for Rule 3 - Register</a>.</p>
<div id="rule4">
<h2 id="rule-4---files">Rule 4 - Files</h2>
</div>
@@ -574,6 +583,9 @@ a case insensitive filesystem.</p></li>
<p>The <code>remarks.md</code> and <code>Makefile</code> are explained in more detail in the Guidelines.</p>
<p>See <a href="../markdown.html">IOCCC markdown guidelines</a>.</p>
<p>See <a href="rules.html#rule-17---packaging">Rule 17 - Packaging</a>.</p>
<p>See FAQ on “<a href="../faq.html#file_perms">What permissions may my files be and what if I need different permissions?</a>”.</p>
<p>See <a href="guidelines.html#mkiocccentry_toolkit">Guidelines for the mkiocccentry toolkit</a>.</p>
<p>See <a href="guidelines.html#makefile">Guidelines for the Makefile</a>.</p>
<div id="rule5">
<h2 id="rule-5---integrity">Rule 5 - Integrity</h2>
</div>
@@ -602,22 +614,14 @@ original form, including the removal of any created files and directories.</p>
<div id="rule7">
<h2 id="rule-7---original-work">Rule 7 - Original Work</h2>
</div>
<p>In short: You wrote it, you own it, and its an original work.</p>
<p>You, the author(s), <strong>MUST</strong> own the contents of your submission, or you <strong>MUST</strong>
have permission from the original owner(s) to its use. If you submit
any content that is owned by others, you <strong>MUST</strong> detail that ownership,
i.e., who owns what, and document the permission you obtained from them
in your <code>remarks.md</code> file.</p>
<p>The IOCCC has a rich history of remarkable winning entries created by
authors who skilfully employed various techniques to develop their code.
While it isn’t required, you are allowed to use tools to develop and
test your submission. These tools may include, but aren’t limited to
code generators, code analysis tools, static code analysis tools, runtime
analysis tools, machine learning tools, natural language models, code
copilot tools, so-called AI services, large language models (LLMs), etc.
If you do make use of such tools or services, then we encourage you to
describe what tools and how you used those tools, in your <code>remarks.md</code> file.</p>
<p>You are permitted to use tools to write your code.</p>
<p>See <a href="rules.html#rule-16---anonymous">Rule 16 - Anonymous</a>.</p>
<p>See <a href="guidelines.html#guideline-7---original-work">Guidelines for Rule 7 - Original Work</a>.</p>
<div id="rule8">
<h2 id="rule-8---submission">Rule 8 - Submission</h2>
</div>
@@ -641,12 +645,12 @@ and
permitted. However, see the guidelines. Each entry <strong>MUST</strong> automate the
build process using <code>bash</code>, <code>gmake</code>, <code>gcc</code>, <code>clang</code>, under a
<a href="https://pubs.opengroup.org/onlinepubs/9799919799/">SUS environment</a>.</p>
<p>Note references to <code>gmake</code> can be any GNU Make compatible tool.</p>
<p><strong>NOTE</strong>: The references to <code>gmake(1)</code> can be any GNU Make compatible tool.</p>
<p>See <a href="rules.html#rule-15---building">Rule 15 - Building</a>.</p>
<div id="rule10">
<h2 id="rule-10---privileges">Rule 10 - Privileges</h2>
</div>
<p>Programs that require special privileges (setuid(2), setgid(2),
<p>Programs that require special privileges (<code>setuid(2)</code>, <code>setgid(2)</code>,
super-user, special owner, special group, etc.) are <strong>HIGHLY DISCOURAGED</strong>.
We do <strong>NOT</strong> guarantee these functions will behave as you expect on our
test platforms. If your program needs special permissions you <strong>MUST</strong>
@@ -679,6 +683,7 @@ is rejected.</p>
version, please indicate that in your <code>remarks.md</code> file of your non-rule
abusing version so that the Judges don’t think you uploaded a duplicate
into a wrong slot by mistake.</p>
<p>See <a href="guidelines.html#guideline-11---abuse">Guidelines for Rule 11 - Abuse</a>.</p>
<div id="rule12">
<h2 id="rule-12---utf-8">Rule 12 - UTF-8</h2>
</div>
@@ -732,6 +737,8 @@ environments and systems are available in the search
GNU long name options <code>--example</code> or extensions like <code>grep -P</code>.</p>
<p>Do <strong>NOT</strong> assume that <code>.</code> (current directory) is in the <code>$PATH</code> environment variable.</p>
<p>See <a href="rules.html#rule-4---files">Rule 4 - Files</a>.</p>
<p>See FAQ on “<a href="../faq.html#makefile_details">What are the detailed recommendations for a submission Makefile?</a>”.</p>
<p>See <a href="guidelines.html#guideline-15---building">Guidelines for Rule 15 - Building</a>.</p>
<div id="rule16">
<h2 id="rule-16---anonymous">Rule 16 - Anonymous</h2>
</div>
@@ -754,27 +761,33 @@ directory depths of <strong>4</strong>. The maximum number of files, excluding
<code>prog.c</code>, <code>remarks.md</code>, <code>Makefile</code>, <code>prog.alt.c</code>, <code>try.sh</code>, <code>try.alt.sh</code>,
<code>.info.json</code> and <code>.auth.json</code> is <strong>31</strong>. And the maximum file-path
component is <strong>38</strong> and maximum path length is <strong>60</strong>.</p>
<p>The submission <strong>MUST</strong> be a <code>.txz</code> compressed tarball as constructed by
<code>mkiocccentry(1)</code>, which <strong>MUST</strong> be within <strong>[1..3999971]</strong> bytes in size.
The sum of all file lengths, after unpacking from the tarball, <strong>MUST</strong> be
less than <code>27651*1024</code> bytes.</p>
<p>The tarball file <strong>MUST</strong> pass all <code>txzchk(1)</code> checks and the tarball
filename <strong>MUST</strong> pass all <code>fnamchk(1)</code> checks. You may <strong>NOT</strong> submit a tarball
created by the <code>-d</code> or <code>-s</code> seed options of <code>mkiocccentry(1)</code>.</p>
<p>The submission <strong>MUST</strong> be a <code>.txz</code> compressed tarball (i.e., tarball compressed by <code>xz(1)</code>)
as constructed by <code>mkiocccentry(1)</code>, which <strong>MUST</strong> be within <strong>[1..3999971]</strong> bytes in size.</p>
<p>The tarball <strong>MUST</strong> be a <strong>v7 format</strong> tarball.</p>
<p>The sum of all file lengths, after unpacking from the tarball, <strong>MUST</strong> be
less than <code>27651*1024</code> (<strong>28314624</strong>) bytes.</p>
<p>The submission <strong>MUST</strong> be a tarball file that <strong>MUST</strong> pass all <code>txzchk(1)</code> checks, and the tarball
filename <strong>MUST</strong> pass all <code>fnamchk(1)</code> checks.</p>
<p>You may <strong>NOT</strong> submit a tarball created by the <code>-d</code>, <code>-e</code>, <strong>NOR</strong> by the <code>-s seed</code> options of <code>mkiocccentry(1)</code>.</p>
<p>The unpacked submission directory <strong>MUST</strong> pass the checks performed by the
current version of <code>chksubmit(1)</code>.</p>
<p>Submissions may <strong>NOT</strong> use a
<a href="https://github.com/ioccc-src/mkiocccentry">mkiocccentry toolkit</a>
command line options that labeled as “<strong>for TESTING purposes</strong>”,
<strong>NOR</strong> labeled as “<strong>for the use by the IOCCC judges only</strong>”,
in their respective man pages.</p>
<p>Submissions may <strong>ONLY</strong> use
<a href="https://github.com/ioccc-src/mkiocccentry">mkiocccentry toolkit</a>
command lines that confirm to the command’s <code>-h</code> “<em>print help message</em>”.</p>
<p>The <code>prog.c</code> file <strong>MUST</strong> pass the <a href="rules.html#rule-2---size">Rule 2 - Size</a>
size checks performed by <code>iocccsize(1)</code>.</p>
<p>The <code>.auth.json</code> and <code>.info.json</code> files <strong>MUST</strong> be compatible with what
<code>mkiocccentry(1)</code> generates.</p>
<p>Submissions that package using older versions of the mkiocccentry
toolkit to are <strong>HIGHLY LIKELY</strong> to be <strong>REJECTED</strong>! Be sure
that you are using the latest tools from the
<p>The <code>.auth.json</code> and <code>.info.json</code> files <strong>MUST</strong> be compatible with what <code>chksubmit(1)</code> generates.</p>
<p>Any submission that fails to pass the checks performed by the most recent version of the
<a href="https://github.com/ioccc-src/mkiocccentry">mkiocccentry toolkit</a>
GitHub repo.</p>
<p>In summary: it is best to use <code>mkioccentry(1)</code> to package your submission,
rather than roll-it-by-hand.</p>
<strong>WILL be rejected</strong>!</p>
<p>See <a href="rules.html#rule-4---files">Rule 4 - Files</a>.</p>
<p>See FAQ on “<a href="../faq.html#mkiocccentry">What is the mkiocccentry tool, how do I obtain it and how do I use it?</a>”.</p>
<p>See <a href="guidelines.html#guideline-17---packaging">Guidelines for Rule 17 - Packaging</a>.</p>
<div id="rule18">
<h2 id="rule-18---license">Rule 18 - License</h2>
</div>
@@ -789,14 +802,15 @@ Additional rules, both humorous and otherwise, may be added
below this rule in future contests.</p>
<p>See <a href="rules.html#rule-6---free">Rule 6 - Free</a>.</p>
<h2 id="further-reading">Further Reading</h2>
<p>Please read the <a href="guidelines.html">Guidelines</a> next for further commentary on these rules.</p>
<p>Read the
<a href="https://www.ioccc.org/quick-start.html#enter">Entering the IOCCC: the bare minimum you need to know</a>
for an overview of how to enter the contest.</p>
<p>Please read the <a href="guidelines.html">Guidelines</a> next for further commentary on The Rules.</p>
<p>See also the <a href="../faq.html">FAQ</a>.</p>
<p>And now <a href="guidelines.html#fun">for something completely different</a></p>
<p>Consider joining the <a href="https://discord.com/invite/Wa42Qujwnw">IOCCC Discord Server</a>
for discussions about The Rules, questions for the Judges, and <code>C</code> in general.</p>
<p>Leonid A. Broukhis<br />
<p>Leonid A. Broukhis
chongo (Landon Curt Noll) /\cc/\
<!-- AFTER: last line of markdown file: next/rules.md --></p>
next/rules.md
+71 -38
View File
@@ -39,7 +39,7 @@ writing by [contacting the judges](../contact.html).
## Rules Version
These IOCCC Rules are version **29.05 2025-11-21**.
These IOCCC Rules are version **29.08 2025-11-28**.
Be sure to read the [IOCCC guidelines](guidelines.html).
@@ -48,15 +48,23 @@ Be sure to read the [IOCCC guidelines](guidelines.html).
## Rule 0 - Dates
</div>
This IOCCC runs from ${START_DATE_TIME} UTC to ${CLOSE_DATE_TIME} UTC.
This IOCCC runs from **2025-12-03 20:25:12.045045 UTC** to **2026-03-13 17:19:23.293137 UTC**.
This contest will enter the open state on ${OPEN_DATE_TIME} UTC.
This contest will enter the **pending state** on **2025-12-03 20:25:12.045045 UTC**,
allowing people to register for the IOCCC.
This contest will enter the judging state on ${JUDGMENT_DATE_TIME} UTC.
This contest will enter the **open state** on **2025-12-15 18:21:24.273033 UTC**,
allowing people to upload submissions to the [IOCCC submit server](https://submit.ioccc.org).
The above dates are subject to change until the contest is officially open.
This contest will enter the **judging state** on **2026-03-13 17:19:23.293137 UTC**,
when people will no longer be allowed to upload submissions.
**NOTE**: As of this draft, the above dates are TBD (to be determined).
Until the contest enters the **open** state, any or all
of the above **dates and times may change _AT ANY TIME_**!
The above timestamps are in "_YYYY-MM-DD HH:MM:SS.micros UTC_" format.
See [Current status of the IOCCC](../status.html).
<div id="rule1">
@@ -78,6 +86,9 @@ During development this can be checked using `iocccsize(1)`:
iocccsize prog.c
See [Guidelines for Rule 2 - Size](guidelines.html#guideline-2---size).
<div id="rule2a">
### Rule 2a - Gross Size
</div>
@@ -85,6 +96,8 @@ During development this can be checked using `iocccsize(1)`:
The overall maximum size of your `prog.c` program source **MUST NOT**
exceed **4993** bytes.
See [Entering the IOCCC: the bare minimum you need to know](../quick-start.html#enter).
<div id="rule2b">
### Rule 2b - Net Size
@@ -118,6 +131,8 @@ See [Entering the IOCCC: the bare minimum you need to know](../quick-start.html#
See [Rule 8 - Submission](rules.html#rule-8---submission).
See [Guidelines for Rule 3 - Register](guidelines.html#guideline-3---register).
<div id="rule4">
## Rule 4 - Files
@@ -177,6 +192,12 @@ See [IOCCC markdown guidelines](../markdown.html).
See [Rule 17 - Packaging](rules.html#rule-17---packaging).
See FAQ on "[What permissions may my files be and what if I need different permissions?](../faq.html#file_perms)".
See [Guidelines for the mkiocccentry toolkit](guidelines.html#mkiocccentry_toolkit).
See [Guidelines for the Makefile](guidelines.html#makefile).
<div id="rule5">
## Rule 5 - Integrity
@@ -219,26 +240,18 @@ See [Rule 19 - Prime](rules.html#rule-19---prime).
## Rule 7 - Original Work
</div>
In short: You wrote it, you own it, and its an original work.
You, the author(s), **MUST** own the contents of your submission, or you **MUST**
have permission from the original owner(s) to its use. 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 from them
in your `remarks.md` file.
The IOCCC has a rich history of remarkable winning entries created by
authors who skilfully employed various techniques to develop their code.
While it isn't required, you are allowed to use tools to develop and
test your submission. These tools may include, but aren't limited to
code generators, code analysis tools, static code analysis tools, runtime
analysis tools, machine learning tools, natural language models, code
copilot tools, so-called AI services, large language models (LLMs), etc.
If you do make use of such tools or services, then we encourage you to
describe what tools and how you used those tools, in your `remarks.md` file.
You are permitted to use tools to write your code.
See [Rule 16 - Anonymous](rules.html#rule-16---anonymous).
See [Guidelines for Rule 7 - Original Work](guidelines.html#guideline-7---original-work).
<div id="rule8">
## Rule 8 - Submission
@@ -271,7 +284,7 @@ permitted. However, see the guidelines. Each entry **MUST** automate the
build process using `bash`, `gmake`, `gcc`, `clang`, under a
[SUS environment](https://pubs.opengroup.org/onlinepubs/9799919799/).
Note references to `gmake` can be any GNU Make compatible tool.
**NOTE**: The references to `gmake(1)` can be any GNU Make compatible tool.
See [Rule 15 - Building](rules.html#rule-15---building).
@@ -280,7 +293,7 @@ See [Rule 15 - Building](rules.html#rule-15---building).
## Rule 10 - Privileges
</div>
Programs that require special privileges (setuid(2), setgid(2),
Programs that require special privileges (`setuid(2)`, `setgid(2)`,
super-user, special owner, special group, etc.) are **HIGHLY DISCOURAGED**.
We do **NOT** guarantee these functions will behave as you expect on our
test platforms. If your program needs special permissions you **MUST**
@@ -322,6 +335,8 @@ version, please indicate that in your `remarks.md` file of your non-rule
abusing version so that the Judges don't think you uploaded a duplicate
into a wrong slot by mistake.
See [Guidelines for Rule 11 - Abuse](guidelines.html#guideline-11---abuse).
<div id="rule12">
## Rule 12 - UTF-8
@@ -397,6 +412,10 @@ Do **NOT** assume that `.` (current directory) is in the `$PATH` environment var
See [Rule 4 - Files](rules.html#rule-4---files).
See FAQ on "[What are the detailed recommendations for a submission Makefile?](../faq.html#makefile_details)".
See [Guidelines for Rule 15 - Building](guidelines.html#guideline-15---building).
<div id="rule16">
## Rule 16 - Anonymous
@@ -426,35 +445,47 @@ directory depths of **4**. The maximum number of files, excluding
`.info.json` and `.auth.json` is **31**. And the maximum file-path
component is **38** and maximum path length is **60**.
The submission **MUST** be a `.txz` compressed tarball as constructed by
`mkiocccentry(1)`, which **MUST** be within **[1..3999971]** bytes in size.
The sum of all file lengths, after unpacking from the tarball, **MUST** be
less than `27651*1024` bytes.
The submission **MUST** be a `.txz` compressed tarball (i.e., tarball compressed by `xz(1)`)
as constructed by `mkiocccentry(1)`, which **MUST** be within **[1..3999971]** bytes in size.
The tarball file **MUST** pass all `txzchk(1)` checks and the tarball
filename **MUST** pass all `fnamchk(1)` checks. You may **NOT** submit a tarball
created by the `-d` or `-s` seed options of `mkiocccentry(1)`.
The tarball **MUST** be a **v7 format** tarball.
The sum of all file lengths, after unpacking from the tarball, **MUST** be
less than `27651*1024` (**28314624**) bytes.
The submission **MUST** be a tarball file that **MUST** pass all `txzchk(1)` checks, and the tarball
filename **MUST** pass all `fnamchk(1)` checks.
You may **NOT** submit a tarball created by the `-d`, `-e`, **NOR** by the `-s seed` options of `mkiocccentry(1)`.
The unpacked submission directory **MUST** pass the checks performed by the
current version of `chksubmit(1)`.
Submissions may **NOT** use a
[mkiocccentry toolkit](https://github.com/ioccc-src/mkiocccentry)
command line options that labeled as "**for TESTING purposes**",
**NOR** labeled as "**for the use by the IOCCC judges only**",
in their respective man pages.
Submissions may **ONLY** use
[mkiocccentry toolkit](https://github.com/ioccc-src/mkiocccentry)
command lines that confirm to the command's `-h` "_print help message_".
The `prog.c` file **MUST** pass the [Rule 2 - Size](rules.html#rule-2---size)
size checks performed by `iocccsize(1)`.
The `.auth.json` and `.info.json` files **MUST** be compatible with what
`mkiocccentry(1)` generates.
The `.auth.json` and `.info.json` files **MUST** be compatible with what `chksubmit(1)` generates.
Submissions that package using older versions of the mkiocccentry
toolkit to are **HIGHLY LIKELY** to be **REJECTED**! Be sure
that you are using the latest tools from the
Any submission that fails to pass the checks performed by the most recent version of the
[mkiocccentry toolkit](https://github.com/ioccc-src/mkiocccentry)
GitHub repo.
In summary: it is best to use `mkioccentry(1)` to package your submission,
rather than roll-it-by-hand.
**WILL be rejected**!
See [Rule 4 - Files](rules.html#rule-4---files).
See FAQ on "[What is the mkiocccentry tool, how do I obtain it and how do I use it?](../faq.html#mkiocccentry)".
See [Guidelines for Rule 17 - Packaging](guidelines.html#guideline-17---packaging).
<div id="rule18">
## Rule 18 - License
@@ -480,16 +511,18 @@ See [Rule 6 - Free](rules.html#rule-6---free).
## Further Reading
Please read the [Guidelines](guidelines.html) next for further commentary on these rules.
Read the
[Entering the IOCCC: the bare minimum you need to know](https://www.ioccc.org/quick-start.html#enter)
for an overview of how to enter the contest.
Please read the [Guidelines](guidelines.html) next for further commentary on The Rules.
See also the [FAQ](../faq.html).
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.
Leonid A. Broukhis
Leonid A. Broukhis
chongo (Landon Curt Noll) /\\cc/\\
sitemap.xml
+7 -7
View File
@@ -16758,11 +16758,11 @@
</url>
<url>
<loc>https://www.ioccc.org/faq.html</loc>
<lastmod>2025-11-24T13:29:41+00:00</lastmod>
<lastmod>2025-11-29T08:08:30+00:00</lastmod>
</url>
<url>
<loc>https://www.ioccc.org/faq.md</loc>
<lastmod>2025-11-24T13:29:41+00:00</lastmod>
<lastmod>2025-11-29T08:08:21+00:00</lastmod>
</url>
<url>
<loc>https://www.ioccc.org/inc/index.html</loc>
@@ -16826,11 +16826,11 @@
</url>
<url>
<loc>https://www.ioccc.org/next/guidelines.html</loc>
<lastmod>2025-11-29T04:32:18+00:00</lastmod>
<lastmod>2025-11-29T07:45:34+00:00</lastmod>
</url>
<url>
<loc>https://www.ioccc.org/next/guidelines.md</loc>
<lastmod>2025-11-29T04:32:18+00:00</lastmod>
<lastmod>2025-11-29T07:45:29+00:00</lastmod>
</url>
<url>
<loc>https://www.ioccc.org/next/index.html</loc>
@@ -16870,11 +16870,11 @@
</url>
<url>
<loc>https://www.ioccc.org/next/rules.html</loc>
<lastmod>2025-11-29T04:32:18+00:00</lastmod>
<lastmod>2025-11-29T07:45:34+00:00</lastmod>
</url>
<url>
<loc>https://www.ioccc.org/next/rules.md</loc>
<lastmod>2025-11-29T04:32:18+00:00</lastmod>
<lastmod>2025-11-29T07:45:14+00:00</lastmod>
</url>
<url>
<loc>https://www.ioccc.org/next/submit.html</loc>
@@ -16938,7 +16938,7 @@
</url>
<url>
<loc>https://www.ioccc.org/status.html</loc>
<lastmod>2025-11-28T05:02:53+00:00</lastmod>
<lastmod>2025-11-29T08:12:55+00:00</lastmod>
</url>
<url>
<loc>https://www.ioccc.org/status.json</loc>