WARNING: These rules are OUT OF DATE
These rules are a VERY TENTATIVE proposal for the next IOCCC
and are VERY LIKELY to be updated before the next IOCCC.
They are are provided as a VERY TENTATIVE hint at what
MIGHT be used in the next IOCCC. In some cases they might
even be a copy of the rules from the previous IOCCC.
See our
FAQ on “rules, guidelines, tools feedback”.
as well as our
FAQ on “about asking questions”
about these rules.
The IOCCC is closed
The IOCCC is NOT accepting new submissions at this time. See the
IOCCC winning entries page for the entries that have won the
IOCCC in the past.
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.
28th International Obfuscated C Code Contest Official Rules
Copyright © 2024 Leonid A. Broukhis and Landon Curt Noll.
All Rights Reserved. Permission for personal, education or non-profit use is
granted provided this this copyright and notice are included in its entirety
and remains unaltered. All other uses must receive prior permission in
writing by contacting the judges.
IOCCC Rules version
These IOCCC rules are version 28.7 2024-07-11.
IMPORTANT: Be sure to read the IOCCC guidelines.
Change marks
← Lines that start with this symbol indicate a change from the previous IOCCC
Most lines (we sometimes make mistakes) that were modified since the previous
IOCCC start with a solid 4 pixel black left border (or, in the case of a code
block or blockquote, just a vertical bar).
Obfuscate defined:
tr.v. -cated, -cating, -cates.
1a. To render obscure.
1b. To darken.
2. To confuse: his emotions obfuscated his judgment.
[LLat. obfuscare, to darken : ob(intensive) + Lat. fuscare,
to darken < fuscus, dark.] -obfuscation n. obfuscatory adj.
Goals of the Contest
The goals of the IOCCC:
- To write the most Obscure/Obfuscated C program within the IOCCC rules.
- To show the importance of programming style, in an ironic way.
- To stress C compilers with unusual code.
- To illustrate some of the subtleties of the C language.
- To provide a safe forum for poor C code. :-)
Important IOCCC dates
This IOCCC runs from 2024-MMM-DD HH:MM:SS UTC to 202x-MMM-DD HH:MM:SS UTC.
XXX - date/time is TBD - XXX
Until the start of this IOCCC, these IOCCC rules,
IOCCC guidelines and the mkiocccentry
toolkit should be considered
provisional BETA versions and may be adjusted AT ANY TIME.
When the IOCCC is open, the submission URL is:
https://submit.ioccc.org; at all other
times that link is likely to be unresponsive.
Please review our
FAQ on “how to submit”
for important information on how to submit to the IOCCC.
The submit URL should be active on or slightly before 2024-MMM-DD HH:MM:SS UTC.
XXX - date/time is TBD - XXX
Please wait to submit your entries until after that time.
The official IOCCC rules and IOCCC guidelines will be
available on the official IOCCC website on or slightly before
the start of this IOCCC. The mkiocccentry
toolkit may be obtained at any time
at the report mkiocccentry bugs.
Please recheck on or after the start of this IOCCC to be sure you
are using the correct versions of these items before using the IOCCC
submission URL.
IOCCC RULES
To help us with the volume of submissions, we ask that you follow these rules:
Rule 0
We need a rule 0. :-)
Rule 1
Your submission must be a complete program.
Rule 2
The size rule requires your submission to satisfy BOTH Rule 2a and Rule 2b:
Rule 2a
The size of your program source should not exceed 4993 bytes.
If you use the most recently released official IOCCC submission
packaging tool (hereby referred to as mkiocccentry(1)
), which we STRONGLY
recommend you do (see also Rule 17), then the mkiocccentry(1)
tool will warn you if there appears to be a Rule 2a violation.
The mkiocccentry(1)
tool will give you the option of overriding the Rule 2a warning.
Overriding a Rule 2a warning carries a fair amount of risk that your submission
will be rejected. Be sure to consult the IOCCC guidelines
ahead of time if you plan to override the Rule 2a warning.
If you do override the Rule 2a warning from the
mkiocccentry(1)
tool, or otherwise plan to violate Rule 2a, then
you MUST CLEARLY EXPLAIN THE RATIONALE of why you are doing so in your
remarks.md
file. Even if you do explain this in your remarks.md
file your
submission may still be rejected.
You may check your code prior to submission by giving the filename
as a command like argument to the iocccsize(1)
tool. For example:
./iocccsize prog.c
Rule 2b
When the filename of your program source is given as a command line argument to the latest version
of the official IOCCC size tool (hereby referred to as iocccsize(1)
), the
value printed should NOT exceed 2503.
The source to iocccsize(1)
may be found in the
mkiocccentry repo.
If you use the mkiocccentry(1)
tool, which we STRONGLY recommend
you do (again, see also Rule 17),
then mkiocccentry(1)
will invoke iocccsize(1)
before packaging your submission.
The mkiocccentry(1)
tool will give you the option of overriding the Rule 2b warning.
Overriding a Rule 2b warning carries a fair amount of risk that your submission
will be rejected. Be sure to consult the IOCCC guidelines
ahead of time if you plan to override the Rule 2b warning.
If you do override the Rule 2b warning from the mkiocccentry(1)
tool,
or otherwise plan to violate Rule 2a, then you MUST CLEARLY EXPLAIN THE RATIONALE
of why you are doing so in your remarks.md
file. Even if you do explain this in your remarks.md
file
your submission may still be rejected.
You may check your code prior to submission by giving the filename
as a command like argument to the iocccsize(1)
tool. For example:
./iocccsize prog.c
Rule 3
Submissions should be performed using the instructions outlined in our
FAQ on “how to submit”
To submit to an open IOCCC, you must use the IOCCC submit
server. Unless the IOCCC is open, that link will
likely be unresponsive.
The submit URL should be active on or slightly before 2024-MMM-DD HH:MM:SS UTC.
XXX - date/time is TBD - XXX
Please wait to submit your entries until after that time.
Rule 4
If your submission is selected as a winner, it may be modified in order
to fit into the structure of the Official IOCCC winner website.
For example, your submission’s Makefile
might be modified.
Your source code will be the file prog.c
. The compiled binary
will be called prog
. If you submission requires different filenames,
then modify your submission’s Makefile
to COPY (NOT move)
the files accordingly.
See also Rule 5, Rule 18 and Rule 21.
Rule 5
Your submission MUST not modify the content or filename of any part of your
original submission including, but not limited to prog.c
, the Makefile
(that we create from your how to build instructions), as well as any data
files you submit.
If you submission wishes to modify such content, it MUST first copy the
file to a new filename and then modify that copy.
Rule 6
I am not a rule, I am a free(void *human);
‼️
while (!(ioccc(rule(you(are(number(6)))))) {
ha_ha_ha();
}
Rule 7
The obfuscated C program must be an original work that you own.
You (the author(s)) must own the contents of your submission OR
you must have permission from the owner(s) to submit their content
under the following license:
CC BY-SA 4.0 DEED Attribution-ShareAlike 4.0 International
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.
Please note that the IOCCC size tool is NOT an original work.
Rule 8
Entries must be received prior to the end of this IOCCC which is 2024-MMM-DD HH:MM:SS UTC.
XXX - date/time is TBD - XXX
A confirmation of submission will be sent to the submitting email address
before the close of the contest.
Rule 9
Each person may submit up to and including 10.000000 (ten) entries per contest.
Each submission must be submitted separately.
Rule 10
Entries requiring human interaction to be initially compiled are not
permitted. However, see the guidelines.
Rule 11
Programs that require special privileges (setuid(2)
, setgid(2)
,
super-user, special owner, special group, etc.) are still 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 document this fact, and explain why
it is needed in your submissions remarks.md
file.
Rule 12
Legal abuse of the rules is somewhat encouraged. A submission that, in
the opinion of the judges, violates the rules will be disqualified.
Submissions that attempt to abuse the rules MUST** try to justify why
their rule abuse is legal, in the remarks.md
file.
Rule 13
Any C source that fails to compile because of unescaped octets with
the high bit set (octet value >= 128) might be rejected.
Rule 14
Any C source that fails to compile because of lines with trailing
control-M’s (i.e., lines with a tailing octet 015
) might be rejected.
Please do NOT put trailing control-M’s on remarks file lines.
Please check to be sure, before submitting, that you have removed
any control-M at the end of remark file lines.
Rule 15
In order to register for the IOCCC, you MUST have a valid email address.
The judges are not responsible for delays in email, please plan
enough time for one automated exchange of email as part of your
submission.
See the
FAQ on “how to register”
for details.
Rule 16
You are STRONGLY encouraged to submit a previously unpublished AND
original submission. Submissions that are similar to previous entries are
discouraged. As we judge anonymously, submissions that have already
been published may be disqualified.
Rule 17
TL;DR Rule 17 - Use mkiocccentry(1)
This is a COMPLEX rule. Violating this rule will cause your submission to REJECTED!
To help you avoid such a rejection, you are HIGHLY ENCOURAGED to use the mkiocccentry(1)
tool,
based on the latest release of the mkiocccentry repo,
to form your submission’s xz compressed tarball.
The mkiocccentry repo
contains IMPORTANT tools such as:
The above mentioned tools will help you verify that your submission
conforms to Rule 17.
Each above mentioned tools has a -h
option that provides command
line help. For additional details, see the tools’ man pages and the
guidelines.
You do not explicitly need to invoke jparse(1)
but the jparse(8)
library will be used when compiling various tools.
Of course you can invoke jparse(1)
if you wish to validate your own JSON
data file or some other JSON file.
Rule 17 - The COMPLEX details
Each submission MUST be in the form of a xz compressed tarball.
The xz compressed tarball filename must be of the form:
^submit.username-slot_num.[1-9][0-9]{9,}.txz$
… where username
is your IOCCC registration username in the form of a
UUID (see
RFC 9562 for
details), and where slot_num
is a single decimal digit integer
(i.e., >= 0
and < 9
).
In particular, username
is in the form of:
xxxxxxxx-xxxx-4xxx-axxx-xxxxxxxxxxxx
where x
is a hexadecimal digit in the
range [0-9a-f]
. And yes, there is a 4 (UUID version 4) and an a
(UUID variant
1) in there.
Your xz compressed tarball MUST contain, at a minimum, the following files:
Makefile
prog.c
remarks.md
.info.json
.auth.json
The .info.json
must be valid JSON and pass the chkentry(1)
tests.
It is generated by the mkiocccentry(1)
tool.
The .auth.json
must be valid JSON and pass the chkentry(1)
tests.
It is generated by the mkiocccentry(1)
tool.
You submission may have additional files, however the filenames of those additional files MUST:
The mkiocccentry(1)
tool will not package any files that do not meet
those requirements.
The Makefile
MUST be a non-empty file in GNU
Makefile form. See the
Makefile.example,
the
FAQ on “submission Makefile”
and the
FAQ on “Makefile compatibility”
for help.
The remarks.md
MUST be a non-empty file in markdown form. See also
Rule 18 and our
FAQ on “remarks.md”
and our
FAQ on “markdown practices”.
See also the markdown syntax guide
and the CommonMark Spec.
The xz compressed tarball file MUST be less than or equal 3999971 octets in size.
When your submission’s xz compressed tarball is uncompressed,
the total size of your submission: the sum of the size of the program,
hints, comments, build and info files MUST be less than or equal
to 28314624 octets (27651K) in size.
Your submission’s xz compressed tarball MUST pass the txzchk(1)
test. See
the guidelines for more details on this tool.
You are HIGHLY ENCOURAGED to use the mkiocccentry(1)
tool to form your
submission’s xz compressed tarball. See the guidelines for
more details on this tool and the mkiocccentry
repo.
Your entry may NOT have subdirectories. However, you can provide files that
are in different directories as mkiocccentry(1)
will copy them to the work
directory (see the guidelines for more details).
Filenames in your entry (that is, not including the files generated by the
mkiocccentry(1)
tool or the tools it or any other tool invokes) MUST:
Be less than 100 characters in length
NOT have a /
(excluding the entry directory that
the mkiocccentry(1)
tool generates).
NOT contain a path component of: .
(that is, with
the exception of files generated by mkiocccentry(1)
itself, it must have
NO .
).
NOT contain a path component of: ..
(that is,
NO ..
).
Match the regular expression
^[0-9A-Za-z][0-9A-Za-z._+-]*$
(again, excluding files generated by
mkiocccentry(1)
).
Additionally, the tarball MUST have the following files (generated
by the mkiocccentry(1)
tool):
The txzchk(1)
tool will verify these (and other things) for you and
the chkentry(1)
tool will do additional checks on the contents of the
.auth.json
and .info.json
files (including JSON validity). If these checks
fail it is an error and mkiocccentry(1)
will fail. In this case it is very
possibly a bug; please report it as a bug at the mkiocccentry issues
page.
The tarball filename MUST pass fnamchk(1)
; the tool txzchk(1)
will run fnamchk(1)
as part of its algorithm. If you use mkiocccentry(1)
there should be no problem but if you were to package things manually it is
possible there could be a problem and this poses a big risk of violating Rule
17.
The fnamchk(1)
, which txzchk(1)
executes, will verify that the
filename is correct.
These checks MUST PASS.
Where Rule 17 and the tools from the latest
release of the mkiocccentry repo
conflict, the IOCCC Judges will use their best judgment which
is likely to favor mkiocccentry repo code.
This means you should MAKE SURE that you use mkiocccentry(1)
to
package your submission; mkiocccentry(1)
will run the above mentioned tools
(that do not act on the tarball) before creating the tarball and after the
tarball is created it will then verify that the tarball is okay by running
txzchk(1)
on it.
MAKE SURE you use the correct release of the repository; you should do this
AFTER the contest opens (pull any changes or if you prefer download the
repository via the download option at GitHub).
We recommend that you run make
and then install the tools (and man pages) via
make install
(as root or using sudo(1)
to help you run these tools from your
submission’s directory. The make install
will install in /usr/local
.
These tools will link in the jparse(8)
library; chkentry(1)
uses the parser
to validate the JSON but the other tools
use parts of the library as well.
If you run into a problem with one or more of these tools, PLEASE report it
as a bug at the mkiocccentry issues
page,
making sure to run bug_report.sh
. See the guidelines
for help here and also read our
FAQ on “mkiocccentry repo bugs”.
At the risk of stating the obvious: submissions that violate Rule
17 will be rejected, so be sure to use the latest release of the
mkiocccentry repo, to form and test
your submission’s xz compressed tarball. Do NOT assume you have the most
recent release without pulling or downloading via GitHub and make sure you
do this AFTER the contest status has changed to
open.
Rule 18
The entirety of your submission must be submitted under the following license:
CC BY-SA 4.0 DEED Attribution-ShareAlike 4.0 International
You (the author(s)) MUST own the contents of your submission OR
you MUST HAVE PERMISSION from the owner(s) to submit their content.
You MUST NOT submit anything that cannot be submitted under that license.
Rule 19
The remarks.md
file, a required non-empty file, must be written in
markdown format. See the Daring Fireball Markdown:
Basics.
We currently use pandoc to convert markdown to HTML.
Please see our FAQ “remarks.md” and the IOCCC markdown
guidelines for additional markdown guidance.
Rule 20
The how to build instructions must be in Makefile format. See the FAQ about
make(1) compatibility the IOCCC
supports for more details.
You are ENCOURAGED to use
Makefile.example,
renamed as Makefile
of course, for help in constructing your Makefile
.
The target of the Makefile must be called prog
. The original
C source file must be called prog.c
.
To invoke the C compiler, use ${CC}
. To invoke the C preprocessor use
${CPP}
.
Do NOT assume that .
(the current directory) is in the $PATH
.
Your Makefile
MUST use a syntax that is compatible with bash(1)
and GNU make(1)
. You are ENCOURAGED to use set SHELL= bash
in
your Makefile
.
Assume that commands commonly found in Single UNIX
Specification
environments and systems that conform to the Single UNIX
Specification are
available in the $PATH
search path.
Rule 21
Your submission MUST NOT create or modify files above the current directory
with the exception of the /tmp
and the /var/tmp
directories. Your submission
MAY create subdirectories below the current directory, or in /tmp
,
or in /var/tmp
provided that .
is NOT the first octet in any
directory name or filename you create.
Rule 22
Catch 22:
Your source code, data files, remarks and program output MUST NOT
identify the authors of your code. The judges STRONGLY PREFER to
NOT know who is submitting entries to the IOCCC.
Even if you are a previous IOCCC winner, catch 22 still applies.
Identifying the author(s) of your submission in an obvious way anywhere
within your code, data, remarks or program output (unless you are
Peter Honeyman or pretending to be Peter Honeyman) will be grounds
for disqualification of your submission.
Yes, Virginia, WE REALLY MEAN IT!
Rule 23
This prime rule number is reserved for future use.
Rule 24
Even though 24 is not prime, you should still see Rule 23.
Rule 25
The IOCCC rule set needs more than 5^2 rules: see Rule 26.
Rule 26
“The quick brown fox jumps over the lazy dog”.
“Pack my box with five dozen liquor jugs.”
“How vexingly quick daft zebras jump!”
“Sphinx of black quartz, judge my vow.”
“Waltz, bad nymph, for quick jigs vex.”
“Mr. Jock, TV quiz PhD, bags few lynx.”
“abcdefg, hijklmnop, qrstu&v, wxy&z.”
Rule 27
Unless otherwise needed, Rule 27 is reserved for something cubic. :-)
Rule 28
Rule 28 is a perfect way end to the list of IOCCC rules
as we do NOT plan to have 496 rules. :-)
For questions or comments about the contest, see Contacting the IOCCC.
Be SURE to review the IOCCC Rules and Guidelines as
IOCCC rules and the IOCCC guidelines may (and
often do) change from year to year.
You should be sure you have the current IOCCC rules and
IOCCC guidelines prior to submitting entries.
See the Official IOCCC website news for additional information.
For the updates and breaking IOCCC news, you are encouraged to follow
the IOCCC on Mastodon account. 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.
Leonid A. Broukhis
chongo (Landon Curt Noll) /\cc/\
Jump to: top