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 about providing feedback as well as our FAQ 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.3 2024-07-01.

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 the | symbol.

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 check the How to enter FAQ 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 mkiocccentry repo.

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 at: the How to enter FAQ.

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 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 the IOCCC in the FAQ 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.

| You do not explicitly need to invoke jparse(1) but the jparse(8) library will be used when compiling various tools.

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

| The .auth.json must be valid JSON and pass the chkentry(1) test.

| 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 Makefile must be a non-empty file in GNU Makefile form. See the Makefile.example, the FAQ about your submission’s Makefile and the FAQ about IOCCC Makefile compatibility for help.

| The remarks.md must be a non-empty file in markdown form. See also Rule 18 and our FAQ about what to put in your remarks.md.

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

| You are HIGHLY ENCOURAGED to use the mkiocccentry(1) tool to form your submission’s xz compressed tarball.

| Your entry may NOT have subdirectories.

| Filenames in your entry (that is, not including the files generated by the mkiocccentry(1) tool or the tools it 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 for you and the chkentry(1) tool will do additional checks on the contents of the .auth.json and .info.json files.

| The tarball filename MUST pass fnamchk(1); the tool txzchk(1) which is run by mkiocccentry(1) before packaging your tarball will run fnamchk(1).

| 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 MAKE SURE that you use mkiocccentry(1) to package your submission; mkiocccentry(1) will run the above mentioned tools before creating the tarball.

| To state 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.

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 about what to put in your 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 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 about 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