WARNING: These rules are TENTATIVE

One might think of them as a beta release for the IOCCC that is about to open.

IMPORTANT: All tentative rules and guidelines are subject to change by the IOCCC judges at any time. See both the IOCCC news and the IOCCC Mastodon feed as sometimes the IOCCC judges mention changes there.

See our FAQ on “rules, guidelines, tools feedback” as well as our 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”.

The IOCCC is pending

While the IOCCC is not open now, there is a tentative opening date for the next IOCCC.

Comments and suggestions on these preliminary rules are welcome. See the FAQ for how to suggest, correct or provide feedback about thse rules.

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.

Jump to: top

Jump to: top

These IOCCC rules are version 28.17 2024-12-30.

The markdown form of these rules is available for download.

IMPORTANT: Be sure to read the IOCCC guidelines.

Jump to: top

← 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).

Jump to: top

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.

Jump to: top

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. :-)

Jump to: top

This IOCCC runs from 2024-12-29 23:58:13.213455 UTC to 2025-04-01 23:29:31.374143 UTC.

This contest will enter the pending state on or about 2024-12-29 23:58:13.213455 UTC.

This contest will enter the open state on 2025-01-31 23:19:17.130705 UTC.

This contest will enter the judging state on 2025-04-01 23:29:31.374143 UTC.

IMPORTANT NOTE: Until the content enters the open state, any or all of the above dates and times may change!

Those who register while the contest status is pending will receive email with their submit server Username and Initial password from an IOCCC judge shortly after the contest status becomes open.

Once an IOCCC judge emails you your Username and Initial password, you will have 72 hours to change your submit server initial password. If you do not change your Initial password in time, you will have to re-register.

Because it takes time (maybe even a few days) for an IOCCC judge to process your registration and email you your initial login and password, you should MAKE SURE you give yourself enough time before the contest closes. In other words, DO NOT WAIT UNTIL THE FINAL DAYS of the contest to register! The IOCCC judges are NOT responsible for delayed or lost email, nor for those who wait until the last minute to try to register!

See the FAQ on “obtaining and compiling the mkiocccentry tools” and the FAQ on “how to enter the IOCCC” as that FAQ has import details on how to register as well as how to upload your submission for the IOCCC.

Jump to: top

To help us with the volume of submissions, we ask that you follow these rules:

Jump to: top

Just as C starts at 0, so the IOCCC starts at rule 0. :-)

The “Important IOCCC dates” section above is part of this rule.

Jump to: top

Your submission must be a complete program.

Jump to: top

The size rule requires your submission to satisfy BOTH Rule 2a and Rule 2b:

Jump to: top

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

Jump to: top

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

Jump to: top

You must register in order to submit your entry to the IOCCC. You may register while the contest is either pending or open.

See the FAQ on “how to register and submit to the IOCCC” for instructions on registering and participating in the IOCCC, as the process has changed from previous years!

When the contest is open, an IOCCC judge will email you your submit server Username and Initial password. This takes some time (maybe even a few days) for an IOCCC judge to process your registration and email you your initial login and password.

Those who register while the contest status is pending will receive email with their submit server Username and Initial password from an IOCCC judge shortly after the contest status becomes open.

Once an IOCCC judge emails you your Username and Initial password, you will have 72 hours to change your submit server initial password. If you do not change your Initial password in time, you will have to re-register.

Because it takes time (maybe even a few days) for an IOCCC judge to process your registration and email you your initial login and password, you should MAKE SURE you give yourself enough time before the contest closes. In other words, DO NOT WAIT UNTIL THE FINAL DAYS of the contest to register! The IOCCC judges are NOT responsible for delayed or lost email, nor for those who wait until the last minute to try to register!

For those who have registered and received by email, their submit server Username and Initial password from an IOCCC judge, you may upload your submission to the submit server only while the contest open.

The submit server, in accordance with Rule 17, places a limit of 3999971 octets on the size of your upload.

You are STRONGLY advised to use the mkiocccentry(1) tool as found in the mkiocccentry repo to form the file to upload to the submit server.

See the FAQ on “obtaining and compiling the mkiocccentry tools” for more information about the mkiocccentry(1) tool.

While the contest is open, you may modify your previously uploaded submission by rebuilding your submission with the mkiocccentry(1) tool and then re-uploading it to the same slot no the submit server.

Once the contest enters the judging state, you will NOT be allowed to upload your submission files.

The submit server will become active when the contest is open. Until the contest status becomes open, the submit server may be offline and/or unresponsive.

See the FAQ on “obtaining and compiling the mkiocccentry tools” and the FAQ on “how to enter the IOCCC” as that FAQ has import details on how to register as well as how to upload your submission for the IOCCC.

Jump to: top

If your submission is selected as a winning entry, then your submission 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.

Jump to: top

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 needs (or wishes :-) ) to modify such content, it MUST first copy the file to a new filename and then modify that copy.

You may use your submission to form a copy, or you can make use of your Makefile to form that copy.

If you do make a copy and then modify that copy, please be sure that the clobber rule of your Makefile removes that copy in order to restore the contents if your submission to its original submission.

Jump to: top

I am not a rule, I am a free(void *human); ‼️

        while (!(ioccc(rule(you(are(number(6)))))) {
                ha_ha_ha();
        }

Jump to: top

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, the tools in the mkiocccentry repo and the tools and library in the jparse repo (that the mkiocccentry repo clones) are NOT original works, unless of course you’re the respective authors, in which case they are. Of course, neither are any of the previous winning entries, unless of course you’re the winner! :-)

See also Rule 5, Rule 18 and Rule 21.

Jump to: top

Submissions may only be uploaded to the IOCCC submit server while the contest is open.

Once the contest is in the judging state (or closed), you may NOT upload submissions.

While the contest is open or in the judging state, the IOCCC judges may (but are not required to) modify the slot comment of your submission to indicate that they have received it. If uploaded submission is malformed, the IOCCC judges may (but are not required to) modify the slot comment accordingly.

See the “Important IOCCC dates” section above for when these contest states are scheduled.

See also Rule 17.

Jump to: top

Each person may submit up to and including 10.000000 (ten in base 10) entries per contest.

Each submission must be submitted separately.

Jump to: top

Entries requiring human interaction to be initially compiled are not permitted. However, see the guidelines.

Jump to: top

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.

Jump to: top

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.

Jump to: top

7 out of 13 UTF-8 characters in C code agree that this rule number is lucky enough to be a prime number.

Jump to: top

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.

Jump to: top

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.

Jump to: top

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.

Jump to: top

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 and libraries such as:

• chkentry(1)

• iocccsize(1)

• mkiocccentry(1)

• txzchk(1)

• fnamchk(1)

• jparse(1) (and other tools) and jparse(3) (which chkentry(1) uses)

The above mentioned tools will help you verify that your submission conforms to Rule 17.

Each above mentioned tool 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(3) library will be used when compiling the tools.

Of course you can invoke jparse(1) if you wish to validate a JSON file but the only JSON files you might want to validate for the IOCCC are validated by chkentry(1), and that is what you should use to make sure you conform to this rule.

IMPORTANT: Make SURE you have the most recent version of the mkiocccentry toolkit! Not doing so will put you at a great risk of violating this rule! See the FAQ on “obtaining the mkiocccentry toolkit” for more details.

Jump to: top

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:

• Be less than 100 characters in length.

• Match the regular expression: ^[0-9A-Za-z][0-9A-Za-z._+-]*$

The mkiocccentry(1) tool will not package any files that do not meet those requirements.

The Makefile MUST be a non-empty file in GNU Makefile form. See the Makefile section in the guidelines, 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” and our markdown guidelines.

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):

• .auth.json which contains information about the author or authors (that will only be looked at if the submission wins).

• .info.json which contains information about the entry.

The txzchk(1) tool will verify these (and other things) for you and the 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. If any step fails it is an error and submitting the submission will result in violating this rule.

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). See the FAQ on “obtaining mkiocccentry” for more help on ensuring you do have the most up to date release.

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. However, you do not have to install them, but in that case you’ll have to run it from the toolkit’s directory or use the correct options to specify the path to the necessary tools, and also specify the path to your files.

These tools will link in the jparse(3) 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.

Jump to: top

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.

Jump to: top

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.

Jump to: top

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. See the Makefile section in the guidelines for more details.

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.

When make clobber is invoked, we request that submission be restored to its original submission state. For example, any temporary files created during the build process, or during execution should be removed by the clobber rule.

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.

Jump to: top

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.

See also Rule 5.

Jump to: top

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!

Jump to: top

This prime rule number is reserved for future use.

Jump to: top

Even though 24 is not prime, you should still see Rule 23.

Jump to: top

The IOCCC rule set needs more than 5^2 rules: see Rule 26.

Jump to: top

“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.”

Jump to: top

Unless otherwise needed, Rule 27 is reserved for something cubic. :-)

Jump to: top

Rule 28 is a perfect way end to the list of IOCCC rules as we do NOT plan to have 496 rules. :-)

Jump to: top

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.

See the FAQ on “obtaining and compiling the mkiocccentry tools” and the FAQ on “how to enter the IOCCC” as that FAQ has import details on how to register as well as how to upload your submission for the IOCCC.

Jump to: top

Leonid A. Broukhis
chongo (Landon Curt Noll) /\cc/\

---

Jump to: top