From 4939cda9e1c644ff60eb4432b1ca1dec39469bfc Mon Sep 17 00:00:00 2001 From: Cody Boone Ferguson <53008573+xexyl@users.noreply.github.com> Date: Sat, 29 Nov 2025 10:15:47 -0800 Subject: [PATCH] Restore Makefile section in guidelines Other fixes were made as well, including in the rules. More work has to be done still. --- next/guidelines.html | 431 +++++++++++++++++++++++++++-------- next/guidelines.md | 529 ++++++++++++++++++++++++++++++++++--------- next/rules.html | 8 +- next/rules.md | 8 +- 4 files changed, 775 insertions(+), 201 deletions(-) diff --git a/next/guidelines.html b/next/guidelines.html index d03abd544..6c0fb86b4 100644 --- a/next/guidelines.html +++ b/next/guidelines.html @@ -452,36 +452,15 @@ - -

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 guidelines 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 guidelines. 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 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 this copyright and notice are included in its entirety +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.

-

IOCCC Guidelines version

+

Guidelines Version

These IOCCC guidelines are version 29.01 2025-11-29.

@@ -535,7 +514,7 @@ because of the iocccsize(1) algorithm.

Jump to: top

-

Guidelines for Rule 3 - Register for the contest

+

Guidelines for Rule 3 - Register for the IOCCC

See FAQ on “What is an author handle?”.

@@ -557,10 +536,10 @@ because of the iocccsize(1) algorithm.

  • Etc.
  • The IOCCC has a rich history of remarkable winning entries created by -authors who skillfully employed various techniques to develop their code.

    -

    If you do make use of such tools or services, then we ENCOURAGE you to describe -how you used such tools in your remarks.md file.

    -

    In short: You created it, you own it, and its an original work, or you have explicit permission.

    +authors who skillfully employed various techniques to develop their code. +If you do make use of such tools or services, then we ENCOURAGE you to +describe how you used such tools in your remarks.md file.

    +

    In short: You created it, you own it, its an original work, or you have explicit permission to the work.

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

    Jump to: top

    @@ -568,40 +547,36 @@ how you used such tools in your remarks.md file.

    Guidelines for Rule 11 - Legal rule abuse

    -

    We try to avoid limiting creativity in our IOCCC rules so -we leave the contest open for creative rule interpretation.

    We do realize that there are holes in the IOCCC rules, and invite -submitters to attempt to exploit them.

    +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 IOCCC rules.

    -

    When we do need to plug a hole in the IOCCC rules or -IOCCC guidelines, we will attempt to use a very small plug, +

    When we do need to plug a hole in the IOCCC rules +or IOCCC guidelines, we will attempt to use a very small plug, if not smaller.

    Or, maybe not. :-)

    -

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

    -

    Legal rule abuse is encouraged to help promote creativity. Rule abuse -submissions, regardless of if they receive an award, result in changes to -the next year’s IOCCC rules and IOCCC guidelines.

    -

    Legal abuse of the IOCCC rules is NOT an invitation to violate the -IOCCC rules. A submission that violates the rules in the -opinion of the IOCCC judges, WILL be -disqualified. RULE ABUSE CARRIES A CERTAIN LEVEL OF RISK! If you -have a submission that might otherwise be interesting, you might want to -submit two versions; one that does not abuse the IOCCC 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.

    +

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

    +

    Legal abuse of the IOCCC rules is NOT an invitation to violate +the IOCCC rules (especailly Rule 17 - +Packaging ). A submission that violates the +rules in the opinion of the IOCCC judges, +WILL be disqualified. RULE ABUSE CARRIES A CERTAIN LEVEL OF RISK!

    If you intend to abuse the IOCCC rules, -indicate so in your remarks.md file. You MUST try to justify +indicate so in your remarks.md file. You MUST try to justify, plead, beg, why you consider your rule abuse to be allowed under the -IOCCC rules. That is, you must plead your case as to why -your submission is valid. Humor and/or creativity help plead a case. +IOCCC 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 the IOCCC rules.

    +

    If you have a submission that might otherwise be interesting, you might want to +submit two versions; one that does not abuse the IOCCC 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 about Rule 2a - Gross Size and/or about @@ -611,14 +586,11 @@ rule and submit a submission anyway, you MUST try to justify wh IOCCC judges should not reject your submission due to a rule violation, and you would be wise to do this towards the top of your remarks.md file.

    -

    Abusing the web submission procedure tends to annoy us more -than amuse us. Spend your creative energy on content of your -submission rather than on the submission process itself.

    We are often asked why the contest IOCCC rules and IOCCC -guidelines 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 IOCCC rules and IOCCC guidelines in +guidelines 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 IOCCC rules and IOCCC 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 them and “drive a @@ -630,7 +602,7 @@ are only part of the overall contest. Even so, one might think the contest IOCCC rules and IOCCC guidelines 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 specifications and requirements from marketing, sales, +sometimes conflicting, balloning 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 the IOCCC rules and IOCCC guidelines are written in obfuscated form.

    @@ -640,13 +612,13 @@ This is one of the reasons why the IOCCC rules and

    Guidelines for Rule 15 - GNU Makefile

    -

    You may use git, or services such as GitHub +

    You may use git, or services such as GitHub to develop and maintain your submission. However, we DISLIKE submissions that require such services in order to build/compile your submission.

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

    -

    We will use the make(1) tool, your Makefile, as well as tools found in the +

    We will use the GNU make(1) tool, your Makefile, as well as tools found in the Single UNIX Specification environments, and commonly found on systems that reasonably conform to the Single UNIX Specification @@ -664,7 +636,7 @@ course.

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

    +As use of using older versions of the mkiocccentry toolkit to 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 @@ -714,10 +686,12 @@ FAQ on “What are the detailed recommend FAQ on “What are the details behind Rule 17 - Use mkiocccentry?”.

    Jump to: top

    + +
    + +

    Guidelines for the mkiocccentry toolkit

    - -

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

    You REALLY SHOULD use the latest mkiocccentry toolkit +are LIKELY to be REJECTED! So you REALLY SHOULD use the latest mkiocccentry toolkit to package your own submission.

    The mkiocccentry(1) tool runs a number of checks by way of these -mkiocccentry toolkit -tools:

    +mkiocccentry toolkit tools:

    -

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

    +

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

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

    Do NOT use chkentry(1) command line options that are labeled “for the use by the IOCCC judges only” -in the chksubmit(1) (or chkentry(1)) man page(s).

    +in the chksubmit(1) (or chkentry(1)) man page(s). +Similarly do NOT use chkentry(1) command line options marked “for the use +by the IOCCC 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
    +
    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, -that will allow you to later use mkiocccentry -i answers ... to reuse those same answers.

    +so later enter mkiocccentry -i answers ... to reuse those same answers.

    The mkiocccentry -A answers ... does the same thing except that the answers 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 do NOT want, such as a -change in your code that violates a detected rule.

    +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 wish to test that your submission passes the mkiocccentry(1) tests -without having to type in in answers each time, you can use the -d or -s seed +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
    +
    mkiocccentry -d workdir topdir

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

    The mkiocccentry(1) tool creates an xz(1) compressed v7 format tarball 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
    +
    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 @@ -785,7 +764,7 @@ run txzchk(1), which will also run fnamchk(1), as part

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

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

    +compressed tarball will NOT be generated: this is a feature, not a bug!

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

    @@ -795,9 +774,8 @@ then in order to run a tool outside the repo directory you will have to specify mkiocccentry(1) command line options to locate required tools such as chkentry(1) (mkiocccentry -C chkentry ..), txzchk(1) (mkiocccentry -T txzchk ..), and fnamchk(1) (mkiocccentry -F fnamchk ..).

    -

    The mkiocccentry(1) tool will ignore any filename that begins with a “.” (dot).

    -

    The mkiocccentry(1) tool will ignore any directory tree with a directory name that begins with a “.” (dot).

    -

    The mkiocccentry(1) tool will all files that begin with COPYING, COPYRIGHT, and LICENSE, regardless +

    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 with COPYING, 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):

    @@ -848,9 +826,275 @@ FAQ on “What is mkiocccentry in simpl

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

    Jump to: top

    +
    +
    +

    Makefiles

    +
    +
    +

    +We recommend AND encourage you to use the example Makefile, +as the starting point for your submission’s required Makefile: +

    + +

    +Feel free to modify the Makefile to suit your obfuscation +needs. +

    +

    +Please add a space between the = and the value of variables, in the +Makefile, making sure that the = comes immediately after the name. See the +example Makefile for examples. +

    +

    +The rest of this section and its subsections will assume that you are using some +variant of the example Makefile, again renamed as Makefile. +

    +

    +We suggest that you compile your submission with a commonly available +-std=gnu17 (ISO C 2017 with GNU extensions) C compiler, via clang(1) +and/or gcc(1). +

    +
    +
    +

    Default compiler flags

    +
    +
    +

    +Unless you clearly state otherwise in your remarks.md file, AND put in +your submission’s Makefile, we will compile using -std=gnu17 -O3! +

    +

    +It is OK if you need to require your submission to NOT be compiled +using the default -std=gnu17 -O3 settings. Simply explain why +your submission should NOT be compiled using -std=gnu17 -O3 in +your remarks.md file, AND adjust your Makefile accordingly. +

    +

    +One reason that you might have to change the flags, is that the optimiser is +known to break some programs, but there are certainly other possible valid +reasons. Again, just update the Makefile and explain it in your remarks.md. +See the optimiser section for details for changing optimiser +flags. +

    +

    +For more fun when it comes to optimisers breaking code, see +1986/marshall/compilers.html. +

    +
    +

    Default compiler

    +
    +

    +IMPORTANT NOTE: The use of -std=gnu17 does NOT imply the use of the gcc +compiler! We often start by compiling using the clang C compiler instead. +

    +

    +PLEASE NOTE: in macOS, the compiler gcc found at /usr/bin/gcc is +in truth the clang compiler, as /usr/bin/gcc --version will show! +

    +
    +
    +

    C standard

    +
    +
    +

    +You may change the standard under which your submission is compiled +by modifying the CSTD Makefile variable. For example, to use c99 instead: +

    +
        CSTD= -std=c99
    +
    +
    +
    +
    +
    +

    Default optimisation level

    +
    +
    +
    +
    +
    +

    +You may change the level of optimization and compiler debug level +that your submission is compiled with, by modifying the OPT Makefile variable. +For example, to compile without optimization, and to include debug symbols: +

    +
        OPT= -O0 -g3
    +
    +
    +

    Compiler warnings

    +
    +
    +

    +The default warning flags are set via the CWARN variable, as shown in the +example Makefile: +

    +
        # Common C compiler warning flags
    +    #
    +    CWARN= -Wall -Wextra ${CSILENCE} ${CUNKNOWN}
    +

    +For details on CSILENCE and CUNKNOWN, see the section on disabling +warnings. +

    +
    +

    The -Weverything option

    +
    +

    +For compilers, such as clang, that have the -Weverything option, +while you may wish to try it, you should read our +FAQ on “clang -Weverything”. +We do NOT recommend that you put +the use of -Weverything into your submission’s Makefile for the reasons +cited there. This goes even if your version does not trigger a warning as some +other version might! +

    +

    +On the other hand, if ${CC} has “clang” in the name, the example Makefile will +automatically enable -Weverything, so you might have to use -Wno-foo +options anyway, as detailed below. See the +FAQ on “-Weverything” +for more details. +

    +

    +If “clang” is NOT in ${CC}, the CWARN variable will not be further +modified. +

    +

    +There is no real penalty for compiler warnings. Sometimes +compiler warnings cannot be helped: especially in the case of +obfuscated C. :-) So if you cannot easily get rid of a compiler +warning, try not to fret too much. +

    +

    +We LIKE code that has a minimum of warnings, especially under the +more strict -Wall -Wextra -pedantic mode: +

    +
        CWARN= -Wall -Wextra -pedantic
    +

    +The two previous guidelines might be thought by some as being somewhat +contradictory. Isn’t life, and isn’t trying to satisfy “contradictory customer +requirements” all too often like that? :-) Try to minimize warnings if you +can. +

    +

    +If you manage to produce very few warnings, or perhaps no warnings at +all under the -Wall -Wextra -pedantic mode, then by all means brag about it in +your remarks.md file AND BE SURE TO TELL US the OS, OS version, compiler +and compiler version in which you observed this occurring (in case our OS and +compiler produces a different result: so your submission won’t be penalized for +not meeting your claims). +

    +

    +On the other hand, some warnings cannot be disabled and are enabled by compilers +without any warning option specified. These are sometimes inevitable in +obfuscated code and even in some non-obfuscated code, and you should not worry +about this, though it might be worth pointing out. +

    +

    +For instance, some compilers like to warn about use of pointers as arrays, which seems to +be dubious, as it obviously can’t (always) be avoided, being a big part of C, so +you should not worry about this either; this is the warning +-Wunsafe-buffer-usage and the way to disable it is -Wno-unsafe-buffer-usage. +See also the +FAQ on “forced warnings” +and the +FAQ on “-Weverything”. +

    +

    Disabling warnings

    +

    +If you do have to disable warnings due to -Weverything automatically being +included, you might wish to state this fact in your remarks.md file. +And even without -Weverything there can be warnings, as noted above. +

    +

    +If your submission issues lots of warnings but is otherwise +marvelously obfuscated in multiple levels, don’t worry about it. Nevertheless, +be sure that the warnings do not constitute a potential “show stopper” +compiler problem. Be sure that compilers such as both gcc and clang won’t +produce a compiler error and refuse to compile your code: unless for some +reason that is what you intend to happen in which case document that too in your +remarks.md file. :-) +

    +

    All other things being equal, a program that must turn off fewer +warnings will be considered better, for certain values of better.

    +

    +To turn off a compiler warning, in your submission’s Makefile, +try something such as: +

    +
        CSILENCE= -Wno-some-thing -Wno-another-thing
    +

    +For instance: +

    +
        CSILENCE= -Wno-parentheses -Wno-binding-in-condition -Wno-misleading-indentation
    +

    +If you do add “-Wno-foo” to your Makefile, consider changing: +

    +
        CUNKNOWN=
    +

    +to: +

    +
        CUNKNOWN= -Wno-unknown-warning-option
    +

    +Some compilers have reported this as an error, however, and if you have +such a compiler you might want to not add it, or at least note in your +remarks.md file, which OS, OS version, compiler and compiler version +that has such a problem. +

    +
    +

    Defining macros in the Makefile

    +
    +

    +If you need to define something on the compile line, use +the CDEFINE Makefile variable. For example: +

    +
        CDEFINE= -Dfoo -Dbar=baz
    +

    +NOTE: just because we offer a default way to use the -D option, we still +do not like excess use of -D to get past size limits, especially since you +could use #define in your code instead. +

    +
    +

    Include files in the Makefile

    +
    +

    +If you need to include a file (as in #include) on the command line, use the +CINCLUDE Makefile variable. For example: +

    +
        CINCLUDE= -include stdio.h
    +
    +

    Magic in the Makefile

    +
    +

    +If you need to add other “magic” flags to your compile line, +use the COTHER Makefile variable. For example: +

    +
        COTHER= -fno-math-errno
    +

    +NOTE: We only recommend using “magic” flags if BOTH gcc +and clang support it. +

    +

    +Again, please note that in macOS, /usr/bin/gcc is actually clang! +

    +
    +

    The clobber rule

    +
    +

    +When make clobber is invoked, we request that submissions be restored +to their original submission state. For example, any temporary files +(including the compiled program(s)) created during the build process, or +during execution should be removed by the clobber rule. In other words, the +only things that should be in the directory after running make clobber is what +is in your submission tarball itself. +

    General Guidelines

    +
    + +
    +

    General Overall Guidelines

    These guideline are hints and suggestions, NOT IOCCC rules.

    While submissions that violate guideline are allowed, submissions that remain within the IOCCC guidelines are preferred.

    @@ -922,10 +1166,12 @@ misleading comments and variable names might be a VERY GOOD START

    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 Makefile section, renamed as Makefile of course. This makes it easier for the IOCCC judges @@ -1196,8 +1442,8 @@ 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.

    -

    One should restrict libcurses to portable features found on BSD -or Linux curses.

    +

    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). @@ -1304,8 +1550,9 @@ is a hint. :-)

    Try to be even more creative!

    Jump to: top

    -

    Fun😄damental Guidelines

    +
    +

    Fun😄damental Guidelines

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

    At least 2 of several reasons for selecting the prime, 2503, for @@ -1412,10 +1659,12 @@ CPU, we might just try your submission on that emulator as well :-)

    it? :-)

    Jump to: top

    + +
    + +

    FOR MORE INFORMATION:

    - -

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

    Be SURE to review the IOCCC Rules and Guidelines as they may (and often do) change from year to year.

    diff --git a/next/guidelines.md b/next/guidelines.md index 6dc1dbb14..061ef30a8 100644 --- a/next/guidelines.md +++ b/next/guidelines.md @@ -1,31 +1,4 @@ - -# The IOCCC is closed - -The IOCCC is **NOT** accepting new submissions at this time. See the -[IOCCC winning entries page](../years.html) for the entries that have won the -IOCCC in the past. - -These guidelines 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](../faq.html#feedback)" -as well as our -FAQ on "[about asking questions](../faq.html#question)" -about these guidelines. You might also find the FAQ in general useful, especially the -FAQ on "[how to enter the IOCCC](../quick-start.html#enter)". - -Watch both [the IOCCC status page](../status.html) and the -[@IOCCC mastodon feed](https://fosstodon.org/@ioccc) for information about -future IOCCC openings. - -**HINT to mastodon users**: You may wish to refresh the [@IOCCC -mastodon feed](https://fosstodon.org/@ioccc) page and/or mastodon -app from time to time to view IOCCC mastodon updates. - - - # 29th International Obfuscated C Code Contest Official Guidelines

    @@ -33,12 +6,12 @@ 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 +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](../contact.html). -# IOCCC Guidelines version +# Guidelines Version

    These IOCCC guidelines are version **29.01 2025-11-29**. @@ -114,7 +87,7 @@ Jump to: [top](#)

    -# Guidelines for [Rule 3 - Register for the contest](rules.html#rule3-register) +# Guidelines for [Rule 3 - Register for the IOCCC](rules.html#rule3-register)
    @@ -143,11 +116,10 @@ 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 to develop their code. +If you do make use of such tools or services, then we **ENCOURAGE you to +describe how you used such tools** in your `remarks.md` file. -If you do make use of such tools or services, then we **ENCOURAGE you to describe -how you used such tools** in your `remarks.md` file. - -In short: You created it, you own it, and its an original work, or you have explicit permission. +In short: You created it, you own it, its an original work, or you have explicit permission to the work. See FAQ on "[May I use AI, LLM, Virtual coding assistants, or similar tools to write my submission?](../faq.html#ai)". @@ -161,49 +133,44 @@ Jump to: [top](#) -We try to avoid limiting creativity in our [IOCCC rules](rules.html) so -we leave the contest open for creative rule interpretation. - We do realize that there are holes in the [IOCCC rules](rules.html), and invite -submitters to attempt to exploit them. +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 [IOCCC rules](rules.html). -When we do need to plug a hole in the [IOCCC rules](rules.html) or -[IOCCC guidelines](guidelines.html), we will attempt to use a very small plug, +When we do need to plug a hole in the [IOCCC rules](rules.html) +or [IOCCC guidelines](guidelines.html), we will attempt to use a very small plug, if not smaller. Or, maybe not. :-) -Legal abuse of the [IOCCC rules](rules.html) is somewhat encouraged. Legal rule abuse -may involve, but is not limited to, doing things that are technically allowed by -the [IOCCC rules](rules.html) and yet do not fit the spirit of what we intended to be -submitted. +Legal rule abuse may involve, but is not limited to, doing things that are +technically allowed by the [IOCCC rules](rules.html) and yet do not fit the spirit of what +we intended to be submitted. -Legal rule abuse is encouraged to help promote creativity. Rule abuse -submissions, regardless of if they receive an award, result in changes to -the next year's [IOCCC rules](rules.html) and [IOCCC guidelines](guidelines.html). - -Legal abuse of the [IOCCC rules](rules.html) is **NOT** an invitation to violate the -[IOCCC rules](rules.html). A submission that violates the [rules](rules.html) in the -opinion of the [IOCCC judges](../judges.html), **WILL** be -disqualified. **_RULE ABUSE CARRIES A CERTAIN LEVEL OF RISK!_** If you -have a submission that might otherwise be interesting, you might want to -submit two versions; one that does not abuse the [IOCCC rules](rules.html) 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. +Legal abuse of the [IOCCC rules](rules.html) is **NOT** an invitation to violate +the [IOCCC rules](rules.html) (especailly [Rule 17 - +Packaging](./rules.html#rule-17---packaging) ). A submission that violates the +[rules](rules.html) in the opinion of the [IOCCC judges](../judges.html), +**WILL** be disqualified. **_RULE ABUSE CARRIES A CERTAIN LEVEL OF RISK!_** If you intend to abuse the [IOCCC rules](rules.html), -indicate so in your `remarks.md` file. You **MUST** try to justify +indicate so in your `remarks.md` file. You **MUST** try to justify, plead, beg, why you consider your rule abuse to be allowed under the -[IOCCC rules](rules.html). That is, you must plead your case as to why -your submission is valid. Humor and/or creativity help plead a case. +[IOCCC rules](rules.html). 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 the [IOCCC rules](rules.html). +If you have a submission that might otherwise be interesting, you might want to +submit two versions; one that does not abuse the [IOCCC rules](rules.html) 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 about [Rule 2a - Gross Size](rules.html#rule-2a-gross-size) and/or about @@ -214,14 +181,11 @@ rule and submit a submission anyway, you **MUST** try to justify why the IOCCC violation, and you would be wise to do this towards the top of your `remarks.md` file. -Abusing the web submission procedure tends to annoy us more -than amuse us. Spend your creative energy on content of your -submission rather than on the submission process itself. - We are often asked why the contest [IOCCC rules](rules.html) and [IOCCC -guidelines](guidelines.html) seem strange or contain mistakes, flaws or -grammatical errors. One reason is that we sometimes make genuine mistakes. But +guidelines](guidelines.html) 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 [IOCCC rules](rules.html) and [IOCCC guidelines](guidelines.html) 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 @@ -235,7 +199,7 @@ are only part of the overall contest. Even so, one might think the contest [IOCCC rules](rules.html) and [IOCCC guidelines](guidelines.html) 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 specifications and requirements from marketing, sales, +sometimes conflicting, balloning 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 the [IOCCC rules](rules.html) and [IOCCC guidelines](guidelines.html) are written in obfuscated form. @@ -250,7 +214,7 @@ Jump to: [top](#) -You may use git, or services such as [GitHub](https://www.github.com) +You may use `git,` or services such as [GitHub](https://www.github.com) to develop and maintain your submission. However, we **DISLIKE** submissions that **require** such services in order to build/compile your submission. @@ -258,7 +222,7 @@ Submissions will be judged in an environment that has no **IDE**. Any submission that fails to compile/build because it requires an **IDE** will be rejected. -We will use the `make(1)` tool, your `Makefile`, as well as tools found in the +We will use the `GNU make(1)` tool, your `Makefile`, as well as tools found in the [Single UNIX Specification](https://en.wikipedia.org/wiki/Single_UNIX_Specification) environments, and commonly found on systems that reasonably conform to the [Single UNIX Specification](https://en.wikipedia.org/wiki/Single_UNIX_Specification) @@ -280,9 +244,10 @@ Jump to: [top](#) + We **STRONGLY** recommend you **do** install the most recent release of [mkiocccentry toolkit](https://github.com/ioccc-src/mkiocccentry) -as use of using older versions of the mkiocccentry toolkit to are **HIGHLY LIKELY** to be **REJECTED**! +As use of using older versions of the mkiocccentry toolkit to 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. @@ -352,11 +317,10 @@ FAQ on "[What are the details behind Rule 17 - Use mkiocccentry?](../faq.html#ru Jump to: [top](#) -
    -
    +
    +
    + # Guidelines for the mkiocccentry toolkit -
    -
    The [IOCCC submit server](https://submit.ioccc.org), and related services use the **most recent version** of the @@ -366,11 +330,11 @@ submissions that package using older versions of the are **LIKELY** to be **REJECTED**! You **REALLY SHOULD** use the latest [mkiocccentry toolkit](https://github.com/ioccc-src/mkiocccentry) +are **LIKELY** to be **REJECTED**! So you **REALLY SHOULD** use the latest [mkiocccentry toolkit](https://github.com/ioccc-src/mkiocccentry) to package your own submission. The `mkiocccentry(1)` tool runs a number of checks by way of these -[mkiocccentry toolkit](https://github.com/ioccc-src/mkiocccentry) -tools: +[mkiocccentry toolkit](https://github.com/ioccc-src/mkiocccentry) tools: * iocccsize(1) * txzchk(1) @@ -378,32 +342,34 @@ tools: * chksubmit(1) * chkentry(1) -Do **NOT** use `txzchk(1)` command line options that are labeled "**for TESTING purposes**" -in the `txzchk(1)` man page. +Do **NOT** use `txzchk(1)` or `fnamchk(1)` command line options that are labeled +"**for TESTING purposes**" in their respective man pages. Do **NOT** use `fnamchk(1)` command line options that are labeled "**for TESTING purposes**" in the `fnamchk(1)` man page. Do **NOT** use `chkentry(1)` command line options that are labeled "**for the use by the IOCCC judges only**" in the `chksubmit(1)` (or `chkentry(1)`) man page(s). +Similarly do **NOT** use `chkentry(1)` command line options marked "**for the use +by the IOCCC judges only**" in the `chkentry(1)` man page. To view [mkiocccentry toolkit](https://github.com/ioccc-src/mkiocccentry) 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 +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, -that will allow you to later use `mkiocccentry -i answers ...` to reuse those same answers. +so later enter `mkiocccentry -i answers ...` to reuse those same answers. The `mkiocccentry -A answers ...` does the same thing except that the **answers file will be overwritten**. @@ -412,18 +378,21 @@ The `mkiocccentry -i answers ...` will still be required to confirm "_Yes/No_" q Use `mkiocccentry -Y -i answers ..` to force a yes answers with **great caution** because it might force a yes answer to something you do **NOT** 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 wish to **test** that your submission passes the `mkiocccentry(1)` tests -without having to type in in answers each time, you can use the `-d` or `-s seed` +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 +mkiocccentry -d workdir topdir ``` Do **NOT** submit a tarball formed by `mkiocccentry -d ..` **OR** by @@ -433,7 +402,7 @@ The `mkiocccentry(1)` tool creates an `xz(1)` compressed **v7 format** tarball u command of the form: ``` - cd workdir/UUID-slot_num && tar --format=v7 -cJf submit.UUID-slot_num.timestamp.txz UUID-slot_num +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 @@ -454,7 +423,7 @@ The use of `mkiocccentry -W ....` is **highly discouraged** as this may ignore warnings about a problem that may cause your submission to be **REJECTED!**" If `mkiocccentry` encounters an **error**, the program will exit and the xz -compressed tarball **will NOT be formed**: this is a **feature, not a bug**! +compressed tarball **will NOT be generated**: this is a **feature, not a bug**! If you encounter a **bug** with the [mkiocccentry toolkit](https://github.com/ioccc-src/mkiocccentry) @@ -467,11 +436,9 @@ you will have to specify `mkiocccentry(1)` command line options to locate requir such as `chkentry(1)` (`mkiocccentry -C chkentry ..`), `txzchk(1)` (`mkiocccentry -T txzchk ..`), and `fnamchk(1)` (`mkiocccentry -F fnamchk ..`). -The `mkiocccentry(1)` tool will ignore any filename that begins with a "." (dot). +The `mkiocccentry(1)` tool will ignore any filename or directory that begins with a period (`.`). -The `mkiocccentry(1)` tool will ignore any directory tree with a directory name that begins with a "." (dot). - -The `mkiocccentry(1)` tool will all files that begin with `COPYING`, `COPYRIGHT`, and `LICENSE`, regardless +The `mkiocccentry(1)` tool will ignore all files that begin with `COPYING`, `COPYRIGHT`, and `LICENSE`, regardless of filename case. The `mkiocccentry(1)` tool will reject any of the following files if they are found directly under @@ -540,10 +507,366 @@ FAQ on "[What is the mkiocccentry tool, how do I obtain it and how do I use it]( Jump to: [top](#) +
    +
    +# Makefiles +
    +
    + +

    +We **recommend** AND **encourage** you to use the example Makefile, +as the starting point for your submission's required `Makefile`: +

    + +- [view example Makefile](%%REPO_URL%%/next/Makefile.example) +- download example Makefile + +

    +Feel free to modify the `Makefile` to suit your obfuscation +needs. +

    + +

    +**Please** add a space between the `=` and the value of variables, in the +`Makefile`, making sure that the `=` comes immediately after the name. See the +example `Makefile` for examples. +

    + +

    +The rest of this section and its subsections will assume that you are using some +variant of the example `Makefile`, again renamed as `Makefile`. +

    + +

    +We suggest that you compile your submission with a commonly available +`-std=gnu17` (ISO C 2017 with GNU extensions) C compiler, via `clang(1)` +and/or `gcc(1)`. +

    + +
    +
    +## Default compiler flags +
    +
    + +

    +Unless you **clearly state** otherwise in your `remarks.md` file, **AND** put in +your submission's `Makefile`, we **will** compile using `-std=gnu17 -O3`! +

    + +

    +It **is OK** if you need to require your submission to **NOT be** compiled +using the default `-std=gnu17 -O3` settings. Simply **explain why** +your submission should NOT be compiled using `-std=gnu17 -O3` in +your `remarks.md` file, **AND** adjust your `Makefile` accordingly. +

    + +

    +One reason that you might have to change the flags, is that the optimiser is +known to break some programs, but there are certainly other possible valid +reasons. Again, just update the `Makefile` and explain it in your `remarks.md`. +See the [optimiser section](#optimiser) for details for changing optimiser +flags. +

    + +

    +For more fun when it comes to optimisers breaking code, see +[1986/marshall/compilers.html](../1986/marshall/compilers.html). +

    + + +
    +## Default compiler +
    + +

    +**IMPORTANT NOTE**: The use of `-std=gnu17` does **NOT** imply the use of the `gcc` +compiler! We often start by compiling using the **clang** C compiler instead. +

    + +

    +**PLEASE NOTE**: in macOS, the compiler `gcc` found at `/usr/bin/gcc` is +in truth the `clang` compiler, as `/usr/bin/gcc --version` will show! +

    + + +
    +
    +## C standard +
    +
    + +

    +You may change the standard under which your submission is compiled +by modifying the `CSTD` Makefile variable. For example, to use `c99` instead: +

    + + +``` + CSTD= -std=c99 +``` + +
    +
    +
    +
    +
    +## Default optimisation level +
    +
    +
    +
    +
    + +

    +You may change the level of optimization and compiler debug level +that your submission is compiled with, by modifying the `OPT` Makefile variable. +For example, to compile without optimization, and to include debug symbols: +

    + +``` + OPT= -O0 -g3 +``` + +
    +
    +## Compiler warnings +
    +
    + +

    +The default warning flags are set via the `CWARN` variable, as shown in the +example `Makefile`: +

    + +``` + # Common C compiler warning flags + # + CWARN= -Wall -Wextra ${CSILENCE} ${CUNKNOWN} +``` + +

    +For details on `CSILENCE` and `CUNKNOWN`, see the [section on disabling +warnings](#disabling-warnings). +

    + +
    +### The `-Weverything` option +
    + +

    +For compilers, such as `clang`, that have the `-Weverything` option, +while you may wish to try it, you should read our +FAQ on "[clang -Weverything](../faq.html#weverything)". +We do **NOT** recommend that you put +the use of `-Weverything` into your submission's `Makefile` for the reasons +cited there. This goes even if your version does not trigger a warning as some +other version might! +

    + +

    +On the other hand, if `${CC}` has "`clang`" in the name, the example `Makefile` will +automatically enable `-Weverything`, so you might have to use `-Wno-foo` +options anyway, as detailed below. See the +FAQ on "[-Weverything](../faq.html#weverything)" +for more details. +

    + +

    +If "`clang`" is NOT in `${CC}`, the `CWARN` variable will not be further +modified. +

    + +

    +There is no real penalty for compiler warnings. Sometimes +compiler warnings cannot be helped: especially in the case of +obfuscated C. :-) So if you cannot easily get rid of a compiler +warning, try not to fret too much. +

    + +

    +We **LIKE** code that has a minimum of warnings, especially under the +more strict ` -Wall -Wextra -pedantic` mode: +

    + +``` + CWARN= -Wall -Wextra -pedantic +``` + +

    +The two previous guidelines might be thought by some as being somewhat +contradictory. Isn't life, and isn't trying to satisfy "contradictory customer +requirements" all too often like that? :-) Try to minimize warnings if you +can. +

    + +

    +If you manage to produce very few warnings, or perhaps no warnings at +all under the `-Wall -Wextra -pedantic` mode, then by all means brag about it in +your `remarks.md` file **AND BE SURE TO TELL US** the OS, OS version, compiler +and compiler version in which you observed this occurring (in case our OS and +compiler produces a different result: so your submission won't be penalized for +not meeting your claims). +

    + +

    +On the other hand, some warnings cannot be disabled and are enabled by compilers +without any warning option specified. These are sometimes inevitable in +obfuscated code and even in some non-obfuscated code, and you should not worry +about this, though it might be worth pointing out. +

    + +

    +For instance, some compilers like to warn about use of pointers as arrays, which seems to +be dubious, as it obviously can't (always) be avoided, being a big part of C, so +you should not worry about this either; this is the warning +`-Wunsafe-buffer-usage` and the way to disable it is `-Wno-unsafe-buffer-usage`. +See also the +FAQ on "[forced warnings](../faq.html#forced_warnings)" +and the +FAQ on "[-Weverything](../faq.html#weverything)". +

    + +
    +## Disabling warnings +
    + +

    +If you do have to disable warnings due to `-Weverything` automatically being +included, you might wish to state this fact in your `remarks.md` file. +And even without `-Weverything` there can be warnings, as noted above. +

    + +

    +If your submission issues lots of warnings but is otherwise +marvelously obfuscated in multiple levels, don't worry about it. Nevertheless, +be sure that the warnings do not constitute a potential "**show stopper**" +compiler problem. Be sure that compilers such as both `gcc` and `clang` won't +produce a compiler **error** and refuse to compile your code: unless for some +reason that is what you intend to happen in which case document that too in your +`remarks.md` file. :-) +

    + +All other things being equal, a program that must turn off fewer +warnings will be considered better, for certain values of better. + +

    +To turn off a compiler warning, in your submission's `Makefile`, +try something such as: +

    + +``` + CSILENCE= -Wno-some-thing -Wno-another-thing +``` + +

    +For instance: +

    + +``` + CSILENCE= -Wno-parentheses -Wno-binding-in-condition -Wno-misleading-indentation +``` + +

    +If you do add "`-Wno-foo`" to your Makefile, consider changing: +

    + +``` + CUNKNOWN= +``` + +

    +to: +

    + +``` + CUNKNOWN= -Wno-unknown-warning-option +``` + +

    +Some compilers have reported this as an error, however, and if you have +such a compiler you might want to not add it, or at least note in your +`remarks.md` file, which OS, OS version, compiler and compiler version +that has such a problem. +

    + +
    +## Defining macros in the Makefile +
    + +

    +If you need to define something on the compile line, use +the `CDEFINE` Makefile variable. For example: +

    + +``` + CDEFINE= -Dfoo -Dbar=baz +``` + +

    +**NOTE**: just because we offer a default way to use the `-D` option, we still +do not like excess use of `-D` to get past size limits, especially since you +could use `#define` in your code instead. +

    + +
    +## Include files in the Makefile +
    + +

    +If you need to include a file (as in `#include`) on the command line, use the +`CINCLUDE` Makefile variable. For example: +

    + +``` + CINCLUDE= -include stdio.h +``` + + +
    +## Magic in the Makefile +
    + +

    +If you need to add other "**magic**" flags to your compile line, +use the `COTHER` Makefile variable. For example: +

    + +``` + COTHER= -fno-math-errno +``` + +

    +**NOTE**: **We only recommend using "_magic_" flags if _BOTH_ `gcc` +_and_ `clang`** support it. +

    + +

    +Again, please note that in macOS, `/usr/bin/gcc` is actually `clang`! +

    + + +
    +## The clobber rule +
    + +

    +When `make clobber` is invoked, we request that submissions be restored +to their original submission state. For example, any temporary files +(**including** the compiled program(s)) created during the build process, or +during execution should be removed by the `clobber` rule. In other words, the +only things that should be in the directory after running `make clobber` is what +is in your submission tarball itself. +

    + +
    # General Guidelines
    +
    + +# General Overall Guidelines These [guideline](guidelines.html) are **hints** and **suggestions**, **NOT** [IOCCC rules](rules.html). @@ -639,11 +962,10 @@ to a great submission! 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 [Makefile section](#makefile), @@ -1006,8 +1328,8 @@ 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. -One should restrict libcurses to portable features found on BSD -or Linux curses. +One should restrict libcurses to portable features found on both BSD +and Linux curses.

    If you do `#include ` make **CERTAIN** you link in curses (i.e. @@ -1136,9 +1458,9 @@ Try to be even more creative! Jump to: [top](#) -

    +
    + # Fun😄damental Guidelines -
    The reason for the times of day are so that key IOCCC events are **calculated** to be a **fun**ctional UTC time. :-) @@ -1271,11 +1593,10 @@ it? :-) Jump to: [top](#) -
    -
    +
    +
    + # FOR MORE INFORMATION: -
    -
    For questions or comments about the contest, see [Contacting the IOCCC](../contact.html). diff --git a/next/rules.html b/next/rules.html index d513d1a8d..3a30f156d 100644 --- a/next/rules.html +++ b/next/rules.html @@ -537,7 +537,7 @@ NOT
    exceed 2503.

    Use mkiocccentry.

    -

    Rule 3 - Register for the contest

    +

    Rule 3 - Register for the IOCCC

    You MUST register, using a valid email address, in order to submit @@ -553,7 +553,7 @@ 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 - Submitting requirements.

    -

    See Guidelines for Rule 3 - Registering for the IOCCC.

    +

    See Guidelines for Rule 3 - Register for the IOCCC.

    Rule 4 - Required files

    @@ -656,7 +656,7 @@ owner(s) to its use. If you submit ANY content that is owned by MUST detail that ownership, i.e., who owns what, and document the permission you obtained from them in your remarks.md file.

    You are permitted to use tools to write your code.

    -

    See Rule 16 - Anonymous Judging.

    +

    See Rule 16 - Anonymous Judging.

    See Guidelines for Rule 7 - Original Work.

    @@ -796,8 +796,10 @@ variable.

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

    See Guidelines for Rule 15 - GNU Makefile compatibility.

    +

    Rule 16 - Anonymous judging

    +

    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 diff --git a/next/rules.md b/next/rules.md index 0a3574ba5..68c519031 100644 --- a/next/rules.md +++ b/next/rules.md @@ -128,7 +128,7 @@ Use mkiocccentry](#rule17-mkiocccentry).

    -## Rule 3 - Register for the contest +## Rule 3 - Register for the IOCCC
    @@ -150,7 +150,7 @@ See [Entering the IOCCC: the bare minimum you need to know](../quick-start.html# See [Rule 8 - Submitting requirements](rules.html#rule8). -See [Guidelines for Rule 3 - Registering for the IOCCC](guidelines.html#guideline-3---register). +See [Guidelines for Rule 3 - Register for the IOCCC](guidelines.html#guideline-3---register).
    @@ -292,7 +292,7 @@ you obtained from them in your `remarks.md` file. You are permitted to use tools to write your code. -See [Rule 16 - Anonymous Judging](rules.html#rule-16-anonymous-judging). +See [Rule 16 - Anonymous Judging](rules.html#rule16-anonymous-judging). See [Guidelines for Rule 7 - Original Work](guidelines.html#guideline-7---original-work). @@ -486,8 +486,10 @@ See [Guidelines for Rule 15 - GNU Makefile compatibility](guidelines.html#guidel
    +
    ## Rule 16 - Anonymous judging
    +
    Your source code, data files, remarks, and program output **MUST NOT** identify the author(s) of your code (unless you are **Peter Honeyman**