The International Obfuscated C Code Contest (original) (raw)

29th International Obfuscated C Code Contest Official Guidelines

Copyright © 2025 Leonid A. Broukhis and Landon Curt Noll.

All Rights Reserved. Permission for personal, education or non-profit use is granted provided 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.

Guidelines Version

These Guidelines are version 29.08 2025-12-02.

The | symbol indicates an change from the previous IOCCC.

Because the IOCCC29 was a substantial rewrite, only important changes from IOCCC28 have been marked.

Guidelines

These Guidelines are hints and suggestions,NOT Rules.

While submissions that violate the Guidelines are allowed, submissions that remain within theGuidelines are preferred.

You are encouraged to review the following FAQs:

While the contest is open, you may modify your previously uploaded submission by rebuilding your submission with themkiocccentry toolkit, and then re-uploading it to the same slot number on the submit server.

Be sure to read the Rules.

While you submission MUST be a C program, there is nothing wrong if your prog.c file happens to also be a code for another language, say an interpreter of JavaScript.

We would prefer if you do not use #include statements just to include lots of data to circumvent Rule 2 - Size restrictions in an excessive way. This is what they invented fopen(3) for. :-)

We would prefer if you do not require lots and lots of implicit defines on the C compiler command line (i.e., lots of -Dfoo, and-Dcurds=whey style command line args to the C compiler in the Makefile) to get around the Rule 2 - Size restrictions in an excessive way.

Some use of #include statements (i.e. -include stdio.h) and/or implicit #defines (i.e. -Dfoo=bar) on the C compiler command line is perfectly reasonable..

As a guide, consider the level of #include statements and/or implicit defines on the C compiler command line that are found in winning Entries, and try to NOT set a new record.

If you believe you need to significantly abuse #include statements and/or implicit defines on the C compiler command line, then try to make a case for why in your submission’s remarks.md file: maybe the Judges won’t reject your submission.

Jump to: top

You should pay attention to our observations on code size and Rule 2 remarks for IOCCC28.

Your submission must satisfy BOTH theRule 2a - Gross Size AND Rule 2b - Net Size rules.

To check your code againstRule 2 - Size restrictions, use theiocccentry(1) tool. For example:

    iocccsize prog.c

The iocccsize(1) algorithm can be summarized as follows:

The size tool counts most C reserved words (keyword, secondary, and selected preprocessor keywords) as 1. The size tool counts all other bytes as 1 excluding ASCII whitespace, and excluding any ‘;’, ‘{’ or ‘}’ followed by ASCII whitespace, and excluding any ‘;’, ‘{’ or ‘}’ byte immediately before the end of file.

ASCII whitespace includes ASCII tab, ASCII space, ASCII newline, ASCII formfeed, and ASCII carriage return.

When ‘;’, ‘{’ or ‘}’ are within a C string, they may still not be counted by the IOCCC size tool.

In cases where the above summary and the algorithm implemented byiocccsize(1) conflict, the algorithm implemented by the minimum required version of iocccsize(1) is preferred by theJudges.

Make sure iocccsize does not flag any issues with your prog.c.

NOTE: by default iocccsize will only report the size, unless the code surpasses the limit.

There a much less need to #define C reserved words in an effort to get around the size limits of Rule 2 - Size restrictions because of the iocccsize(1)algorithm.

Yes Virginia, the previous guideline sentence is an important hint!

Don’t expect the Rule 2 - Size restrictions tochange any time soon.

See the FAQ on “How has the Rule 2 size restrictions rule changed over the years?”.

Jump to: top

If a group of people work on a submission, then they should register for the IOCCC using either a valid group email address, or an email address for one of the authors.

Processing your registration is an activity overseen by a Judge. Please be patient while a Judge processes your registration.

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!

If after a few days you believe your registration hasn’t been process, then contact the Judges.

After your UUID and temporary password are emailed to you, you have up to fortnight (14 days) to login and change your temporary password. If you fail to change your temporary password by that deadline, then you’ll need to contact the Judges by email to request a reset.

See the FAQ on “How to register for the IOCCC”.

See the FAQ on “Entering the IOCCC: the bare minimum you need to know”.

Jump to: top

While it is NOT required, you are allowed to use tools or services such as:

The IOCCC has a rich history of remarkable winning entries created by authors who skillfully employed various techniques (often their own tools) to develop their code. If you do make use of such tools or services, then we ENCOURAGE you to describe how you used such toolsin your remarks.md file.

In short: you created it, you own it, its an original work OR you have explicit permission to the work that you document in your remarks.

See the FAQ on “May I use AI, LLM, Virtual coding assistants, or similar tools to write my submission?”.

Jump to: top

Do NOT register more than one account just to try and get around the limit on the number of submission slots, because if you do and we discover that you did so your submissions will be rejected for violating the rules.

Jump to: top

Don’t forget that the building of your program should be done WITHOUT human intervention. So don’t do things such as:

    prog: prog.c
        #echo this next line requires data from standard input
        cat > prog.c
        ${CC} prog.c -o prog

However, you can do something cute such as making your program do something dumb (or cute) when it is built ‘automatically’, and when it is run with a human involved, do something more clever. For example, one could put in their Makefile:

    prog: prog.c
        ${CC} prog.c -DNON_HUMAN_COMPILE -o prog
        @echo "See remarks section about alternate ways to compile"

and then include special notes in your remarks.md file for alternate / human intervention based building.

Jump to: top

We do realize that there are holes in the Rules, and invite submitters to attempt to apply creative rule interpretation. A rule abuse though, even if not rewarded, may result in a subsequent rule change for future contests.

We sometime award ‘Best abuse of the rules’ or ‘Worst abuse of the rules’, or some variation, to a submission that creatively attempts to exploit a holes in the Rules.

When we do need to plug a hole in the Rules orGuidelines, we will attempt to use a very small plug, if not smaller.

Or, maybe not. :-)

Legal rule abuse may involve, but is not limited to, doing things that are technically allowed by the Rules and yet do not fit the spirit of what we intended to be submitted.

Legal abuse of the Rules is NOT an invitation to violate the Rules (especially Rule 17 - Use mkiocccentry). A submission that violates the rules in the opinion of theJudges, WILL be disqualified. RULE ABUSE CARRIES A CERTAIN LEVEL OF RISK!

If you intend to abuse the Rules, indicate so in yourremarks.md file. You MUST try to justify, plead, beg, why you consider your rule abuse to be allowed under the Rules. Humor or creativity help plead a case.

As there is no guarantee that you will succeed, you might consider submitting an alternate version that conforms to theRules, if it might otherwise be interesting; one that does not abuse the Rules and one that does, making sure to note in the one that does not abuse the rules that this is another version, so that the Judges do not assume you uploaded it by mistake.

If you do bypass the mkiocccentry(1) warnings aboutRule 2a - Gross Sizeand/or aboutRule 2b - Net Size or any other rule and submit it anyway, you MUST try to justify why theJudges should not reject your submission due to a rule violation, and you would be wise to do this towards the top of yourremarks.md file so as not to be overlooked.

We are often asked why the contest Rules andGuidelines seem strange or contain mistakes, flaws, or grammatical errors. One reason is that we sometimes make genuine mistakes, but in many cases such problems, flaws or areas of confusion are deliberate.

Changes to Rules and Guidelines in response to rule abuses, are done in a minimal fashion. Often we will deliberately leave behind holes (or introduce new ones) so that future rule abuse can continue. A clever author should be able to read and “drive a truck through the holes” in the Rules andGuidelines.

At the risk of stating the obvious, this contest is a parody of the software development process. The Rules andGuidelines are only part of the overall contest. Even so, one might think the contest Rules andGuidelines process as a parody of the sometimes tragic mismatch between what a customer (or marketing) wants and what engineering delivers. Real programmers must face obfuscated and sometimes conflicting, ballooning specifications, and requirements from marketing, sales, product management and even from customers themselves on an all too regular basis. This is one of the reasons why theRules and Guidelines are written in obfuscated form.

Jump to: top

The IOCCC no longer discourages the use of multibyte UTF-8 characters in C code.

We DISLIKE C code with trailing control-M’s (\r or \015) that results in compilation failures.

Some non-UNIX/non-Linux tools such as MS Visual C and MS Visual C++ leave trailing control-M’s on lines. Users of such tools should strip off such control-M’s before submitting their submissions. In some cases tools have a “Save As” option that will prevent such trailing control-M’s being added.

If your prog.c is near the Rule 2a Gross Size and/or Rule 2b Net Size limit, you are permitted to NOTend source with a newline. If you need to do this, please document that in your remarks.md file.

If your compiler complains about about not ending in a newline, please note this in your remarks.md file, and if possible add an appropriate-Wno- to the CSILENCE variable in your Makefile.

Jump to: top

Submissions will be judged in an environment that has no IDE. Any submission that fails to compile/build because it requires an IDEwill be rejected.

We will use the GNU make(1) tool, your Makefile, as well as tools found in the Single UNIX Specification(UNIX-like) environments, and commonly found on systems that reasonably conform to the Single UNIX Specificationin the building and compiling of your submission.

Your Makefile MUST be compatible with GNU make and we suggest you use <Makefile.example> as a template, renamed asMakefile of course.

See the FAQ on “What are the detailed recommendations for a submission Makefile?”.

Jump to: top

We STRONGLY recommend you do install the most recent release ofmkiocccentry toolkitbecause use of older versions of the mkiocccentry toolkit are HIGHLY LIKELY to be REJECTED!

If you submit your own JSON files (OTHER THAN .auth.json and.info.json!) then they do NOT have to be valid JSON.

However, if you do provide invalid JSON files, PLEASE document andclearly explain this in your remarks.md file.

An extra file is defined as a file that is not prog.c,prog.alt.c, try.sh, try.alt.sh, remarks.md, Makefile,.auth.json and .info.json: unless it’s not in the top level directory, in which case it IS an extra file.

The non-extra files are considered free files, and do not count towards the Rule 17 - Use mkiocccentry limit of 31 extra files.

If you use an optional filename for something other than their intended use in order to get past the file limit, we will consider that an abuse of rules.

The mkiocccentry generated tarball does NOT reveal who you are! For this reason, the tarball MUST be a v7 format tarball.

You should NOT use a tarball as an extra file for a test-suite unless you have a very good reason for this: if you do include a tarball as an_extra file_, then you MUST specify why in your remarks.md file.

If you DO include a tarball as an extra file, and the build process or the program extracts said tarball(s), the make clobberrule MUST remove the extracted files.

Instead of including a large test-suite that requires a lot of files as part of your submission, if your submission doesn’t require the test-suite to be available to run, then in your remarks.md you could include URL where such a test-suite may be downloaded from and how to use the test-suite to test your submission, assuming it does not reveal who you are, i.e. DO NOT use a GitHub URL which contains your username, in case the judges know who you are. See Rule 16 - Anonymous judging.

If you DO include a tarball then make sure it uses the v7 format. This is because it will not reveal who you are.

See the FAQ on “extra files” for details on how to make a v7 tarball.

We recommend that all markdown files in your submission observe ourIOCCC markdown guidelines.

See the FAQ on “What should I do with the try.sh and try.alt.shscripts?”.

See the FAQ on “What is a .auth.json file?”.

See the FAQ on “What is a .info.json file?”.

See the FAQ on “How can I validate my submission directory?”.

See the FAQ on “What permissions may my files be and what if I need different permissions?”.

See the FAQ on “What are the detailed recommendations for a submission Makefile?”.

See the FAQ on “What are the details behind Rule 17 - Use mkiocccentry?”.

Jump to: top

General Guidelines

Overall Guidelines

The official locale of the IOCCC is C.

You are encouraged to examine the winners of previous contests.

Because the Rules change from year to year, some past winning entries may be rejected this year. What was_was_ unique and novel one year might be ‘old’ the next year.

A submission is usually examined in a number of ways. We typically apply a number of tests to a submission:

You should consider how your submission looks in each of the above tests. You should ask yourself if your submission remains obscure after it has been ‘_cleaned up_’ by the C pre-processor and a C beautifier.

Your submission need not pass all of the above tests as in certain cases, a test is not important.

Submissions that compete for the ‘strangest/most creative source layout’ need not do as well as others in terms of their algorithm.

Given two submissions, we are more inclined to pick the submission that does something interesting when it’s executed.

IMPORTANT: Be sure that your submission works as documented in your remarks.md file.

We sometimes make an effort to debug a submission that has a slight problem, particularly in or near the final round. On the other hand, we have seen some otherwise excellent submissions fall down because they didn’t work as documented.

If you submission has bugs and/or mis-features, you are MUCH BETTERoff documenting such bugs and/or mis-features in your remarks.mdfile.

Consider an example of a prime number printing program that claims that 16 is a prime number. Noting such a bug in yourremarks.md file could save your submission:

“_this submission sometimes prints the 4th power of a prime by mistake_”

Sometimes a strange bug or (mis-)feature can even help the submission! Of course, a correctly working submission might be better.

We tend to look down on a prime number printer that claims that 16 is a prime number. Clever people will note that 16 might be prime under certain conditions. :-) Wise people, when submitting something clever will fully explain such cleverness in their submission’s remarks.md file.

People who are considering to just use some complex mathematical function or state machine to spell out something such as “_hello, world!_” really really, and we do mean REALLY, do need to be more creative.

Consider using misleading or subtle tricks layered on top of or under an appropriate level of obfuscation.

A clean looking program with misleading comments and variable names might be a VERY GOOD START to a great submission!

Try to avoid submissions that play music that some people believe is copyrighted music.

Did we remember to indicate that programs that blatantly use some complex state machine to do something simple, are boring? We think we did. :-)

Given two versions of the same program, one that is a compact blob of code, and the other that is formatted more like a typical C program, we tend to favor the second version. Of course, a third version of the same program that is formatted in an interesting and/or obfuscated way, would definitely win over the first two!

Remember, you can submit more than one submission. See theRules for details (in particular, Rule 8 - Submitting requirements).

Please note that the C source below, besides lacking in obfuscation, isNOT the smallest C source file that when compiled and run, dumps core:

    main;

Unless you specify -fwritable-strings (see COTHER in the example Makefile, described in the FAQ on “What are the detailed recommendations for a submission Makefile”), do not assume this sort of code will work:

    char *T = "So many primes, so little time!";
    ...
    T[14] = ';';    /* modifying a string requires: -fwritable-strings */

Even so, one should probably not assume that this is universally accepted.

Initialized char arrays are OK to write over. For instance, this is OK:

    char b[] = "Is this OK";
    b[9] = 'k';     /* modifying an initialized char array is OK */

Jump to: top

Our Likes and Dislikes

We VERY MUCH LIKE submissions that use an edited variant of the example Makefile, as described and linked to in the FAQ on “What are the detailed recommendations for a submission Makefile?, renamed as Makefile of course.

This makes it easier for the Judges to test your submission. And if your submissions wins, it makes it easier to integrate it into the Official IOCCC winner website.

We VERY MUCH LIKE submissions that have some educational value. This does NOT mean that your submission should not be obfuscated but rather that the IOCCC has moved away from the idea of “spoilers”. You should not encrypt or rot13 content in your remarks.md file.

The above statement does not mean encryption/decryption tools will not win, nor does it mean that if you have such a submission that you could not encrypt some remarks (such as obfuscation details), but if you do so please put them in a separate file and indicate how to decipher it. Please do NOT use any cipher to encrypt your remarks.md.

It is VERY MUCH appreciated if your remarks or prog.c have some educational value. And although educational value is not required, it is an EXCELLENT bonus.

We LIKE submissions that use an edited version of the try.shexample script (and if you have alternate code, the same applies with the try.alt.sh script):

Of course, it is quite possible that only one invocation is possible, so it is not necessarily detrimental to your submission if you do not include one, though we do like interesting and creative uses of submissions. See also the FAQ on “submitting try.sh and try.alt.sh scripts”.

Even if it only has one invocation we still LIKE the try scripts because we use them during judging and in publishing the winning entries.

If you do include a try.sh then PLEASE remove the try rule in the Makefile.

If you do include a try.alt.sh then PLEASE remove the try.altrule in the Makefile.

If you don’t have a prog.alt.c, then PLEASE remove the try.altrule as well.

We tend to DISLIKE programs that:

In order to encourage submission portability, we DISLIKEsubmissions that fail to build unless one is using an IDE. For example, do not mandate that one must use Microsoft Visual Studio to compile your submission.

Jump to: top

About C preprocessor

Doing masses of #defines to obscure the source has become ‘old’. We tend to ‘see thru’ masses of #defines due to our pre-processor tests that we apply. Simply abusing #defines or -Dfoo=bar won’t go as far as a program that is more well rounded in confusion.

Many C compilers DISLIKE the following code, and so do we:

    #define d define
    #d foo             /* <-- don't expect this to turn into #define foo */

In other words, it is a compilation error, and in order to get older IOCCC winning entries that did this to compile, we had to update them to not do this.

When declaring local or global variables, you should declare the type:

    int this_is_fine;

and NOT like this:

    this_is_not;       /* <-- Try to avoid implicit type declarations */

We really DISLIKE submissions that make blatant use of #includeof large data files to get around the source code size limit. This does not mean #include of standard header files, just files you provide, or system files such as /usr/share/dict/words.

On 28 January 2007, the Judges rescinded the requirement that the #in a C preprocessor directive must be the 1st non-whitespace byte.

About compilers

We tend to like less a submission that requires either gcc OR clang. We prefer submissions that can compile underBOTH gcc AND clang. Hint!

We RECOMMEND that the compiler flags you use in your submission’sMakefile are supported by BOTH gcc AND clang.

We DISLIKE the use of obscure compiler flags, especially if gccand/or clang do not support it. We suggest that you not use any really obscure compiler flags if you can help it.

About nested functions

One side effect of the above is that you cannot assume the use of nested functions such as:

     int main() {
|        void please_dont_submit_this() {
|           printf("The machine that goes BING!!\n");
         }
|        please_dont_submit_this();
     }

On 2012 July 20, the Judges rescinded the encouragement of nested functions. Such constructions, while interesting and sometimes amusing, will have to wait until they are required by a C standard that are actually implemented in BOTH gcc AND clang.

We DISLIKE submissions that require the use of-fnested-functions.

About variadic functions

If your submission uses functions that have a variable number of arguments, be careful. Systems implement va_list in a wide variety of ways. Because of this, a number of operations usingva_list are not portable and must not be used:

In particular, do not treat va_list variables as if they were a char **.

We DISLIKE the use of varargs.h. Use stdarg.h instead.

About I/O functions

We DISLIKE the use of gets(3). Use fgets(3) instead.

About tarballs

We tend to DISLIKE the blatant use of tarballs in an attempt to simply get around the extra file number limit. We realize there may be cases where a tarball containing a number of extra files may be needed. Such a need for a tarball MUST be explained in the remarks.mdfile.

On gotos

Using a mass of gotos to obfuscate your code has become old and is unlikely to make it through the final rounds, if it even gets that far.

About exit(3)

The exit(3) function returns void. Some broken systems haveexit(3) return int; your submission should assume that exit(3)returns a void.

What it means to be small

Small programs are best when they are short, obscure and concise. While such programs are not as complex as other winners, they do serve a useful purpose: they are often the only program that people attempt to completely understand. For this reason, we look for programs that are compact, and are instructional.

Programs that claim to be the smallest C source that does something, really better be the smallest such program or they risk being rejected because they do not work as documented.

We suggest that you avoid trying for the ‘smallest self-replicating’ source. The smallest, a zero byte entry, won in1994.

What a one-liner means

One line programs should be short one line programs: say around 80to 132 bytes long. Going well beyond 132 bytes is a bit too long to be called a one-liner in our vague opinion.

About blobs of code

We want to get away from source that is simply a compact blob of bytes. REALLY TRY to be more creative than blob coding. HINT!

Unless you are cramped for space, or unless you are entering the ‘Best one liner’ category, we suggest that you format your program in a more creative way than simply forming excessively long lines.

About size restrictions

The Makefile should not be used to try and get around the size limit. It is one thing to make use of a several -Ds on the compile line to help out, but it is quite another to use many bytes of -Ds in order to try and squeeze the source under the size limit.

Please do not use things like gzip(1) to get around the size limit. This was done years ago; please try to be much more creative.

Your source code, post-pre-processing, should not exceed the size ofMicrosoft Windows. :-)

About environment

The program must compile and link cleanly in a Single UNIX Specification(UNIX-like) environment. Therefore do not assume the system has awindows.h include file:

    #include <windows.h>  /* we DISLIKE this */

Other windows, on the other hand, might be OK: especially where “X marks the spot”. Yet on the third hand, windows are best when they are “unseen” (i.e., not dirty). :-)

You should try to restrict commands used in the build file to commands found in Single UNIX Specification(UNIX-like) environments and systems that conform to the Single UNIX Specification.

You may compile and use your own programs. If you do, try to build and execute from the current directory. This restriction is not a hard and absolute one. The intent is to ensure that the building of your program is reasonably portable.

We prefer programs that are portable across a wide variety of UNIX-like operating systems (e.g., Linux, GNU Hurd, BSD, UNIX, macOS, etc.).

We prefer code that can run on either a 64-bit or 32-bit processor. However, it is UNWISE to assume it will run on an some Intel-like x86 architecture**.

While programs that only run in a specific word size are OK, if you have to pick, choose a 64-bit word size.

If your submission MUST run only on a 64-bit or 32-bit architecture, then you MUST specify the -arch on your command line (see ARCH in the example Makefile, described in the FAQ on “What are the detailed recommendations for a submission Makefile?.

Do not assume a processor word size without specifying -arch. For example:

    ARCH= -m64

Note, however, that some platforms will not necessarily support some architectures. For instance, more recent versions of macOS do NOTsupport 32-bit, and more than zero Judges use it!

About X

X client submissions should be as portable as possible. Submissions that adapt to a wide collection of environments will be favored.

For example, don’t depend on a particular type or size of display.

Don’t assume the use of a particular browser. Instead assume a generic browser that forms to a widely used W3C standard.

Don’t assume a particular sound sub-system or video driver is installed in the OS. Instead, make use of a well known and widely available open source program (one that actually works) to display audio/visual data.

X client submissions should avoid using X related libraries and software that are not in wide spread use.

As of Red Hat RHEL9.0, the X.org server is deprecated. See the FAQ on “Xorg deprecation” for more details. This does not mean that a submission using this will necessarily be rejected, but it would be better if it can support Wayland in some way or another.

We DISLIKE submissions that use proprietary toolkits such as theM*tif, Xv*ew, or OpenL*ok toolkits, since not everyone has them. Use an open source toolkit that is widely and freely available instead.

X client submissions should try to not to depend on particular items in.Xdefaults. If you must do so, be sure to note the required lines in the your remarks.md file.

X client submissions should also not depend on any particular window manager.

About libcurses

One should restrict libcurses to portable features found on both BSD and Linux curses.

If you do #include <curses.h> make CERTAIN you link in curses (i.e. -lcurses) and not ncurses (i.e. -lncurses).

Jump to: top

About ASCII TAB

We DISLIKE the use of ASCII tab characters in markdown files, such as in the required remarks.md file.

We don’t mind the use of ASCII tab characters in your C code. Feel free to use ASCII tab characters if that suits your obfuscation needs. If is perfectly OK to use tab characters elsewhere in your submission, just not in markdown files as this tends annoy us when it comes time to rendering your markdown content as it complicates the process.

If you do use ASCII tab characters in your non-markdown files, be aware that some people may use a tab stop that is different than the common 8 character tab stop.

PLEASE observe our markdown guidelines when forming your submission’s remarks.md file. And if your submission contains additional markdown files, please follow those same Guidelines for those files.

See also Rule 4 - Required files, and the FAQ on “markdown”.

Jump to: top

You are better off explaining what your submission does in yourremarks.md file section rather than leaving it obscure for theJudges as we might miss something and/or be too tired to notice.

We freely admit that interesting, creative or humorous comments in yourremarks.md file help your chances of winning. If you had to read so many twisted submissions, you too would enjoy a good laugh or two. We think the readers of the contest winners do as well. We do read yourremarks.md content during the judging process, so it is worth your while to write a remarkable remarks.md file.

It is a very good idea to, in your remarks.md file, tell us why you think your submission is obfuscated. This is particularly true if your submission has some very subtle obfuscations that we might otherwise overlook. <<– Hint!

Anyone can format their code into a dense blob. A really clever author will try formatting their submission using a “normal” formatting style such that at first glance (if you squint and don’t look at the details) the code might pass for non-obfuscated C. Deceptive comments, and misleading formatting, in some cases, may be a plus. On the other hand, a misleading code style requires more source bytes.

If you do elect to use misleading formatting and comments, we suggest you remark on this point in your remarks.md where you talk about why you think your submission is obfuscated.

If you are pushing up against the size limits, you may be forced into creating a dense blob. Such are the trade-offs that obfuscators face!

We LIKE reading remarks.md files, especially if they contain useful, informative, and even humorous content about your submission. Yes, this is a hint. :-)

We RECOMMEND you put a reasonable amount effort into the content of the remarks.md file: it is a required file for a reason. :-)

Jump to: top

Miscellaneous

While we recognize that UNIX is not a universal operating system, the contest does have a bias towards such systems. In an effort to expand the scope of the contest, we phrase our bias to favor the Single UNIX Specification(UNIX-like).

You are well advised to submit code that conforms to the Single UNIX Specification Version 4.

To quote the Judges:

We LIKE programs that:

Some types of programs can’t excel (anti-tm) in some areas. Your program doesn’t have to excel in all areas, but doing well in several areas really does help.

Try to be even more creative!

If there are limitations in your submission, you are highly encouraged to note such limitations in your remarks.md file. For example if your submission factors values up to a certain size, you might want to state:

This submission factors values up2305567963945518424753102147331756070. Attempting to factor larger values will produce unpredictable results.

The Judges might try to factor the value -5, so you want to might state:

This submission factors positive values up2305567963945518424753102147331756070. Attempting to factor large values will produce unpredictable results.

However the Judges might try to also factor 0, so you might want to state:

This submission factors values between 1 and2305567963945518424753102147331756070. Attempting to factor values outside that range will produce unpredictable results.

Moreover they might try to also factor 3.5 or 0x7, or Fred, so you want to might state:

This submission factors integers between 1 and2305567963945518424753102147331756070. Attempting to factor anything else will produce unpredictable results.

You submission might be better off catching the attempt to factor bogus values and doing something interesting. So you might want to code accordingly and state:

This submission factors integers between 1 and2305567963945518424753102147331756070. Attempting to factor anything else will cause the program to insult your pet fish Eric.

The Judges might not have a pet fish named Eric, so you might want to state:

This submission factors integers between 1 and2305567963945518424753102147331756070. Attempting to factor anything else will cause the program to insult your pet fish Eric, or in the case that you lack such a pet, will insult the pet that you do not have.

When all other things are equal, a submission with fewer limitations will be judged better than a submission with lots of limitations. So you might want to code accordingly and state:

This submission attempts to a factor value of any size provided that the program is given enough time and memory. If the value is not a proper integer, the program might insult a fish named Eric.

Do not fear if you’re not 100% sure of the significance of2305567963945518424753102147331756070 as it is not of prime importance: or is it? :-)

Jump to: top

Guidelines for the mkiocccentry toolkit

The IOCCC submit server, and related services use the most recent version of the mkiocccentry toolkit: submissions that package using older versions of the mkiocccentry toolkit are LIKELY to be REJECTED!

You REALLY SHOULD use the latest mkiocccentry toolkit to package your submission as submissions that use an older version are WILLbe REJECTED!

The mkiocccentry(1) tool runs a number of checks by way of thesemkiocccentry toolkittools:

Do NOT use txzchk(1) or fnamchk(1) command line options that are labelled “for TESTING purposes” in their respective man pages.

Do NOT use fnamchk(1) command line options that are labelled “for TESTING purposes” in the fnamchk(1) man page.

Do NOT use chksubmit(1) command line options that are labelled “for the use by the Judges only” in the chksubmit(1) man page.

Similarly do NOT use chkentry(1) command line options marked “for the use by the Judges only” in the chkentry(1) man page.

To view mkiocccentry toolkit man pages, while your current directory is the top of the source tree:

    man soup/man/man1/mkiocccentry.1
    man soup/man/man1/iocccsize.1
    man soup/man/man1/txzchk.1
    man test_ioccc/man/man1/fnamchk.1
    man soup/man/man1/chksubmit.1
    man soup/man/man1/chkentry.1

The above man(1) commands will show the toolkit man pages without having to install them first.

So that you do not have to repeatedly answer all the mkiocccentry(1)questions, use mkiocccentry -a answers ... to create a file containing the answers you first give, and later enter mkiocccentry -i answers ... to reuse those same answers.

The mkiocccentry -A answers ... does the same thing except that theanswers file will be overwritten.

The mkiocccentry -i answers ... will still be required to confirm “_Yes/No_” questions.

Use mkiocccentry -Y -i answers ... to force a yes answers with great caution because it might force a yes answer to something you doNOT want, such as a change in your code that violates a detected rule.

The mkiocccentry -i answers ... will still be required to confirm “_Yes/No_” questions. While mkiocccentry -Y -i answers ... will force yes answers, use with great caution, because it might force a yes answer to something you do NOT want.

To help with not having to repeatedly enter a UUID, put your UUID into a file and use mkiocccentry -u uuidfile ..., or use mkiocccentry -U UUID ... to give the UUID on the command line. If you also use -a answers or -A answers the UUID will be recorded, assuming it is a valid UUID.

If you wish to test that your submission passes themkiocccentry(1) tests without having to type in answers each time, you can use the -d or -s seed option to mkiocccentry for the tool to pseudo-randomly create answers for you. For example:

    mkiocccentry -d workdir topdir

Do NOT submit a tarball formed by mkiocccentry -d ... OR bymkiocccentry -s seed ... OR by using the test UUID.

The mkiocccentry(1) tool creates an xz(1) compressed v7 formattarball using a tar(1) command of the form:

    cd workdir/UUID-slot_num && tar --format=v7 -cJf submit.UUID-slot_num.timestamp.txz UUID-slot_num

In many places the mkiocccentry(1) tool will prompt you to verify what you input, allowing you to correct details as you go along.

Pressing the “_enter key_” at the mkiocccentry(1) tool prompts will allow you to proceed with a default, however make sure the default is the CORRECT answer.

The mkiocccentry(1) tool will use code from iocccsize(1) which detects a number of issues (such as Rule 2 - Size restrictions) that you may ignore, however ignoring such issues comes with a SIGNIFICANT level of risk!

Once the submission directory has been constructed themkiocccentry(1) tool will run chksubmit(1) to verify everything is well, before forming the tarball.

Once the tarball is formed mkiocccentry(1) will run txzchk(1), which will also run fnamchk(1), as part of its algorithm.

The use of mkiocccentry -W ... is highly discouraged as this may ignore warnings about a problem that may cause your submission to beREJECTED!

The same can be said of mkiocccentry -Y ... , and to a lesser extentmkiocccentry -y ...: the -y is mostly for the test script and the-Y is like -y but even more aggressive.

If mkiocccentry encounters an error, the program will exit and the xz compressed tarball will NOT be generated: this is afeature, not a bug!

If you encounter a bug with the mkiocccentry toolkit PLEASE run thebug_report.sh script to help us out here!

While you don’t have to install the mkiocccentry toolkit, if you don’t, in order to run a tool outside the repo directory you will have to specifymkiocccentry(1) command line options to locate required tools such aschkentry(1) (mkiocccentry -C chkentry ...), txzchk(1)(mkiocccentry -T txzchk ...), and fnamchk(1) (mkiocccentry -F fnamchk ...).

The mkiocccentry(1) tool will ignore any filename or directory that begins with a period (.).

The mkiocccentry(1) tool will ignore all files that begin withCOPYING, COPYRIGHT, and LICENSE, regardless of filename case.

The mkiocccentry(1) tool will reject any of the following files if they are found directly under the top level directory (topdir):

The files listed in the above list are allowed to exist in sub-directories: just NOT directly under the top level directory (topdir).

The mkiocccentry(1) tool evaluates all filenames and directory names in a case independent way: thus FOO, Foo, and foo are considered the SAME file even if your filesystem doesn’t do the same.

Having two or more filenames that differ only by case WILL lead to problems because of the previous statement.

When the mkiocccentry(1) tool ignores a file, that file is NOTincluded as part of your submission.

When the mkiocccentry(1) tool ignores a directory, that directory, and everything under that directory is NOT included as part of your submission.

The mkiocccentry(1) tool will ignore all symlinks.

Creating a directory directly under the top level directory (topdir) that is normally considered to be a regular file, such as a directory named Makefile, prog.alt.c, prog.c, remarks.md, try.alt.sh, or try.sh is NOT a good idea and will likely cause themkiocccentry(1) tool to abort with a fatal error.

The required Makefile and remarks.md files may NOT be empty. This does not mean just 0 bytes but also that it MUST havecontent, and content that is relevant (e.g. a Makefile with just comments is NOT allowed). However, with the exception of theMakefile, the mkiocccentry(1) tool will ONLY check file size.

On the other hand, chksubmit(1) will check that .auth.json and.info.json are valid.

If the optional file try.alt.sh, or try.sh exists and is an empty file, the mkiocccentry(1) tool will abort with a fatal error.

If the mkiocccentry(1) tool encounters anything that isn’t a file, isn’t a directory, and isn’t a symlink (which the tool ignores), themkiocccentry(1) tool to abort with a fatal error.

See the FAQ on “How do I report bugs in an mkiocccentrytool?”.

See Rule 11 - Legal rule abusefor warnings about ignoring mkiocccentry(1) tool warnings.

See the FAQ on “What is the fnamchk tool?”.

See the FAQ on “What is mkiocccentry in simple terms?”.

See the FAQ on “What is the mkiocccentry tool, how do I obtain it and how do I use it”.

Jump to: top

Fun😄damental Guidelines

The reason for the times of day are so that key IOCCC events arecalculated to be a functional UTC time. :-)

At least 2 of several reasons for selecting the prime, 2503, for Rule 2b - Net Size may be found on the“Curios!” about 2503.

The 2503 value for Rule 2b - Net Size is a decimal anagram of the number of the kernel disk pack of one of the judge’s BESM-6.

There may or may not be fewer than 2^7+1 reasons why theseGuidelines seem obfuscated.

Excessively “dotty” use of the chksubmit(1) or chkentry(1)commands suggests that either you like silly things, or that youRTFS with some level of care.

Some people might question what actually constitutes a valid JSON file, given the state of the “_so-called_” JSON spec. :-)

We prefer programs that do not require a fish license: crayons and cat detector vans not withstanding.

This guideline has a change mark at the very start of this line.

While those who are used to temperatures found on dwarf planets (yes Virginia, dwarf planets ARE planets!), such asPluto, might be able to explain to the Walrus why our seas are boiling hot, the question of whether pigs have wings is likely to remain a debatable point to most.

At least one judge prefers to maintain the use of theleap-second as part of the world’s time standard. If your code prints time with seconds, we prefer that your code be capable of printing the time of day during a leap-second where the value in seconds after the minute mark is 60.

The Judges, as a group, have a history giving wide degree of latitude to reasonable submissions. And recently they have had as much longitudinal variation as it is possible to have onEarth. :-)

You are in a maze of twisty guidelines, all different.

There are at least zero Judges who think thatFideism has little or nothing to do with the Judging process.

All generalizations are false, including this one. – Mark Twain

There are more than about 1 typos in this very sentence.

This could be the only guideline that contains the wordfizzbin.

However, do you know how to playfizzbin? You do?!? (Except on Tuesday?)

OK, there are actually 2 guidelines that contain the wordfizzbin, unless you count this one, in which case there are 3. :-)

NOTE: The previous guideline in this spot has been replaced by this guideline:

You very well might not be completely prohibited from failing to not partly misunderstand this particular guideline, but of course, we could not possibly comment! Nevertheless, you are neither prohibited, nor are you fully or partly required to determine that this or the previous sentence is either false and/or perhaps misleading. Therefore, it might be wise for you to not fail to consider to not do so, accordingly. Thank you very much (allegedly).

Any complaints about the above guideline could be addressed to the Speaker of the House of Commons, or to the speaker of your national parliament should you have one.

Please try to avoid this specific individual guideline, if it is at all possible.

We believe that Mark Twain’s quote:

Get your facts first, then you can distort them as you please.

… is a good motto for those writing code for the IOCCC.

We do not recommend submitting systemd source code to the IOCCC, if nothing else because that code is likely to exceed Rule 2 - Size restrictions. This isn’t to say that another highly compact and obfuscated replacement ofinit(8) would not be an interesting submission.

The IOCCC size tooliocccsizeis not an original work unless you are Anthony C Howe, in which case it is original. :-)

The IOCCC tarball validatortxzchkis not an original work unless you are Cody Boone Ferguson, in which case it is original. :-)

Even so, those tools exceed the Rule 2 - Size restrictions so they wouldn’t qualify for the contest anyway.

If the IOCCC judges are feeling like it, they might choose to compile your program for running on an Arduino or a PDP-11. Heck, should we ever find an emulator of 60-bit CDC Cyber CPU, we might just try your submission on that emulator as well :-)

With respect to nested functions, try chkentry -b.

Jump to: top

Further Reading

See the Official IOCCC website news for additional information.

For questions or comments about the contest, see Contacting the IOCCC.

Be SURE to review the current IOCCC Rules and Guidelines as they often change year to year. Especially prior to submitting to the contest.

For the latest IOCCC news, follow the IOCCC on Mastodon. See our FAQ on “Mastodon” for more information.

Also consider joining the IOCCC Discord Server for the latest news, discussions about The Rules, questions for the Judges, and C in general.

Jump to: top