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.

These rules are a TENTATIVE proposal for the next IOCCC and are likely be to be updated before the next IOCCC.

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

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.

29th International Obfuscated C Code Contest Official Rules

Copyright © 2025 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.

Rules version

These IOCCC Rules are version 29.04 2025-11-20.

Be sure to read the IOCCC guidelines.

This IOCCC runs from ${START_DATE_TIME} UTC to ${CLOSE_DATE_TIME} UTC.

This contest will enter the open state on ${OPEN_DATE_TIME} UTC.

This contest will enter the judging state on ${JUDGMENT_DATE_TIME} UTC.

The above dates are subject to change until the contest is officially open.

NOTE: As of this draft, the above dates are TBD (to be determined).

Your submission MUST be a C program.

Rule 2 requires that your submission satisfy BOTH Rule 2a Gross Size and Rule 2b Next Size. During development this can be checked using iocccsize(1):

iocccsize prog.c

The overall maximum size of your prog.c program source MUST NOT exceed 4993 bytes.

When the filename of your program source (i.e., prog.c) is given as a command line argument to the latest version of the official IOCCC size tool (hereby referred to as iocccsize(1)), the value printed MUST NOT exceed 2503.

You MUST register, using a valid email address, in order to submit entries to the IOCCC. You may register while the contest is pending or open.

A few days after registering, you’ll receive your UUID username and temporary password, which you MUST change within 14 days. If you fail to change it in a timely manner, you’ll need to contact the Judges by email to request a reset.

It can take a few days to process your registration and for the server to email your details, therefore make sure to allow yourself ample time to register and submit your entries; DO NOT WAIT UNTIL THE FINAL DAYS to register! The judges are NOT responsible for delayed or lost email or for those who wait until the last minute to try to register!

See Entering the IOCCC: the bare minimum you need to know.

See Rule 8 - Submission.

The submission MUST include at least these files: Makefile, prog.c, remarks.md,.info.json, and .auth.json. The last two MUST be generated by mkiocccenty(1) when packing a submission, and MUST pass the chksubmit(1) tests.

The Makefile, remarks.md,.info.json, and .auth.json MUST have a file size greater than 0.

Your submitted source code MUST be called prog.c. When the Makefile compiles your code, the executable (if applicable) MUST be called prog. The Makefile may compile your source code into other filenames as well.

As prog, prog.alt, prog.alt.o, prog.o may be created by your Makefile, your submission MUST NOT include those files in your top directory, as original content.

Your submission may NOT have any file that starts with COPYING, COPYRIGHT, or LICENSE as those files are reserved by IOCCC.

Your submission may NOT have in the top directory, prog.orig.c, README.md, nor index.html as those files reserved by IOCCC.

Your submission may NOT have in the top directory, any file that matches a file glob pattern form [0-9][0-9][0-9][0-9]_*.tar.bz2 as those files are reserved by IOCCC.

Your submission may ONLY contain files and directories. Other file types such as symlinks, sockets, etc are NOT allowed.

All directories MUST have a file mode of 0755. All files MUST have the file mode of 0444, except for files that end in .sh which must have a mode of 0555.

All files that end in .md MUST be in markdown format. We recommend that markdown files observe our IOCCC markdown guidelines.

All filenames are treated as case insensitive. For example, REMARKS.MD, and Remarks.md, and remarks.md are considered by mkiocccenty(1) to be the SAME file. If you are preparing your submission on a case sensitive filesystem, ensure that your submission will work on a case insensitive filesystem.

The remarks.md and Makefile are explained in more detail in the Guidelines.

See IOCCC markdown guidelines.

See Rule 17 - Packaging.

Your submission MUST NOT modify the filenames or content of any of your original submission, such as prog.c, Makefile, or any supplied data files. To modify files, your program can make a copy or you can use the Makefile to setup working copies. Any working copies MUST be cleaned up by the Makefile clobber target, so as to restore the directory to its original state.

Your submission MUST NOT create or modify directories and files ABOVE the current directory with the exception of the /tmp and the /var/tmp directories as long as the directory name or filename does NOT start with “.” (dot).

The Makefile clobber target MUST be restore your submission into original form, including the removal of any created files and directories.

Your code should be able to run under a SUS environment.

I am NOT a Rule, I am a free(void *human); ‼️

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

See Rule 19 - Prime.

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.

See Rule 16 - Anonymous.

The Submit Server will only accept submissions from those who have registered and only while the contest is open.

The Submit Server places a total submission size limit of 3999971 bytes.

Each account has ten (10.000) submission slots (0..9). Each submission slot should be annotated by the server as to whether its was received, processed, malformed, etc. Please take note of any errors, rectify, and resubmit. In order to avoid potential packaging errors, it is highly recommended to use mkiocccentry(1).

See Rule 3 - Register, Rule 15 - Building, and Rule 17 - Packaging.

Entries requiring human interaction to be initially compiled are NOT permitted. However, see the guidelines. Each entry MUST automated the its build process using bash, gmake, gcc, clang, under a SUS environment.

Note references to gmake can be any GNU Make compatible tool.

See Rule 15 - Building.

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 document this fact and explain why it is needed in your submission’s remarks.md file.

Furthermore, if you need a supplementary program that you include to have these permissions, you will also have to explain this, because these bits are NOT allowed in submissions and those bits will NOT be copied by mkiocccentry(1).

See Rule 4 - Files, and Rule 5 - Purity.

Legal abuse of the rules is somewhat encouraged, but comes with risks. A submission that, in the opinion of the Judges, violates the rules WILL BE DISQUALIFIED. Submissions that plan to abuse the rules MUST justify why their rule abuse is legal (or interesting) in the remarks.md file.

Submission packaging abuse will NOT be tolerated and for this reason its recommended to use mkiocccentry(1). During development you can check your prog.c size limits using iocccsize(1), e.g., iocccsize -v1 prog.c. Overriding problems detected by any of the IOCCC tools risks that the submission will be rejected.

If you do submit a rule abusing or violating submission, then consider also submitting an alternate version in a different submission server slot that does NOT violate the rules in case your rule abuse excuse is rejected.

IMPORTANT: If you do submit such an alternate non-rule abusing 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.

Use of UTF-8 is supported by C89 standard and its updates and so too by the IOCCC.

Any C source that fails to compile because lines contain carriage-returns (CTRL+M, \r) in particular as part of DOS/Windows style newlines might be rejected. Please do NOT put trailing CTRL+M in prog.c, Makefile, or remarks.md files, but instead end lines with Unix newline (line-feed, CTRL+J, \n).

You are permitted, in order to try and squeeze your prog.c under a Rule 2a Gross Size and/or Rule 2b Next Size limits, to NOT end source with a newline. If you need to do this, please document that in your remarks.md file and if your compiler complains about this, document this too and update your Makefile to account for this.

Submissions that are substantially similar to previous winning IOCCC entries are discouraged.

You are allowed to resubmit to a later contest, a submission that didn’t win the IOCCC. If you do so, then you would be well advised to try and enhance and improve your submission. If you do resubmit something that didn’t previously win, then you are encouraged to mention this in your remarks.md file as this sometimes helps.

The Makefile MUST adhere to GNU Makefile syntax. Its recommended that you copy and rename the Makefile.example as template. The primary target of the Makefile MUST be prog and the source file is prog.c. The C compiler and preprocessor MUST be invoked using ${CC} and ${CPP} macros respectively.

The clobber target should clean and restore the submission directory tree to its original state, such as removing temporary files or any modified data files. Don’t assume that git tool chain is installed, i.e., do NOT expect git clean -f to work.

The Makefile MUST use a syntax that is compatible with bash(1) and GNU make(1). You are encouraged to use SHELL= bash in your Makefile; please add a space between the = and the value such as:

SHELL= bash

Assume that commands commonly found in Single UNIX Specification environments and systems are available in the search $PATH. Avoid command options that aren’t part of SUS, such as GNU long name options --example or extensions like grep -P.

Do NOT assume that . (current directory) is in the $PATH environment variable.

See Rule 4 - Files.

Your source code, data files, remarks, and program output MUST NOT identify the author(s) of your code (unless you are Peter Honeyman or pretending to be Peter Honeyman). In order to be impartial the Judges do NOT know who is submitting entries to the IOCCC until final selection is made. Even if you are a past winner, you MUST NOT reveal your identity deliberately or by accident anywhere in your submission. Failure to comply may result in the submission being disqualified.

The files, directories, and paths MUST conform to the limits imposed by mkiocccentry(1), including but NOT limited, to their names, count, path length, directory tree depth, and permissions.

The submission tree may have at most 13 directories and maximum directory depths of 4. The maximum number of files, excluding prog.c, remarks.md, Makefile, prog.alt.c, try.sh, try.alt.sh, .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 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 unpacked submission directory MUST pass the checks performed by the current version of chksubmit(1).

The prog.c file MUST pass the Rule 2 - Size size checks performed by iocccsize(1).

The .auth.json and .info.json files MUST be compatible with what mkiocccentry(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 mkiocccentry toolkit GitHub repo.

In summary: it is best to use mkioccentry(1) to package your submission, rather than roll-it-by-hand.

See Rule 4 - Files.

The entirety of your submission MUST be submitted under the following license:

CC BY-SA 4.0 DEED Attribution-ShareAlike 4.0 International

See Rule 7 - Original Work.

This 19th rule, while prime, is reserved for future abuse 😁. Additional rules, both humorous and otherwise, may be added below this rule in future contests.

See Rule 6 - Free.

Further Reading

Read the Entering the IOCCC: the bare minimum you need to know for an overview of how to enter the contest.

Please read the Guidelines next for further commentary on The Rules.

See also the FAQ.

Consider joining the IOCCC Discord Server for discussions about The Rules, questions for the Judges, and C in general.

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