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.

These IOCCC rules are version 28.7 2024-07-11.

IMPORTANT: Be sure to read the IOCCC guidelines.

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

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.

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

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.

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

We need a rule 0. :-)

Your submission must be a complete program.

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

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

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

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.

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.

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.

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

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

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.

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.

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

Each submission must be submitted separately.

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

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.

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.

Any C source that fails to compile because of unescaped octets with the high bit set (octet value >= 128) might be rejected.

Any C source that fails to compile because of lines with trailing control-M’s (i.e., lines with a tailing octet 015) might be rejected.

Please do NOT put trailing control-M’s on remarks file lines. Please check to be sure, before submitting, that you have removed any control-M at the end of remark file lines.

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.

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.

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:

• chkentry(1)

• iocccsize(1)

• mkiocccentry(1)

• txzchk(1)

• fnamchk(1)

• jparse(1) and jparse(8) (which chkentry(1) uses)

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:

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

• .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.

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.

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.

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.

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.

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.

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!

This prime rule number is reserved for future use.

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

The IOCCC rule set needs more than 5^2 rules: see 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.”

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

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