diff --git a/faq.html b/faq.html index 8f9798f5b..7be272a73 100644 --- a/faq.html +++ b/faq.html @@ -453,7 +453,7 @@

IOCCC FAQ Table of Contents

-

This is FAQ version 28.2.22 2025-08-24.

+

This is FAQ version 28.2.23 2025-11-17.

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

  • Q 0.2: What platform should I assume for my submission?
  • Q 0.3: What should I put in my submission Makefile?
    • @@ -478,15 +477,14 @@
  • Q 1.1: May I use a different source or compiled filename than prog.c or prog?
  • Q 1.2: What is markdown and how does the IOCCC use it?
  • Q 1.3: How do I report bugs in an mkiocccentry tool?
    • -
  • Q 1.4: How may I use subdirectories in my submission if Rule 17 disallows them?
    • -
  • Q 1.5: How can I check if my submission passes tests without having to answer questions?
    • -
  • Q 1.6: What are extra files and how may I include additional files beyond the max allowed?
    • -
  • Q 1.7: May I use AI, LLM, Virtual coding assistants, or similar tools to write my submission?
    • -
  • Q 1.8: What are the details behind Rule 17?
    • -
  • Q 1.9: How can I avoid re-entering my UUID to mkiocccentry?
    • -
  • Q 1.10: How can I avoid having to move or delete my submission directory for the same workdir?
    • -
  • Q 1.11: Can I download my submission tarball from the submit server?
    • -
  • Q 1.12: Can I delete a submission from the submit server?
    • +
  • Q 1.4: How can I check if my submission passes tests without having to answer questions?
    • +
  • Q 1.5: What are extra files and how may I include additional files beyond the max allowed?
    • +
  • Q 1.6: May I use AI, LLM, Virtual coding assistants, or similar tools to write my submission?
    • +
  • Q 1.7: What are the details behind Rule 17?
    • +
  • Q 1.8: How can I avoid re-entering my UUID to mkiocccentry?
    • +
  • Q 1.9: How can I avoid having to move or delete my submission directory for the same workdir?
    • +
  • Q 1.10: Can I download my submission tarball from the submit server?
    • +
  • Q 1.11: Can I delete a submission from the submit server?

    • 2. IOCCC Judging process

    3. The mkiocccentry toolkit: finer details

    4. Compiling IOCCC entries

    IMPORTANT: this MUST NOT match a mandatory filename (see above list) -and chkentry will verify this for you; it is ALSO an error if the +and chksubmit will verify this for you; it is ALSO an error if the filenames are not unique, not POSIX plus + safe chars only, if they are the wrong permission and various other things. In these cases you stand a great risk of having your submission rejected for violating Rule @@ -3018,7 +2574,7 @@ formed - see gettimeofday(2)) second. test_formed_timestamp_usec() in soup/entry_util.c in the mkiocccentry repo. If -this is not the case chkentry(1) will report an error and your +this is not the case chksubmit(1) will report an error and your submission WILL BE rejected!

  • timestamp_epoch (double quoted string)

      @@ -3038,28 +2594,28 @@ this is not the case your submission WILL BE rejected!

      in the mkiocccentry repo. If this is not the case your submission WILL BE rejected!

    -

    This file will be validated with the chkentry(1) tool and if there are any +

    This file will be validated with the chksubmit(1) tool and if there are any problems with it or the submission directory, it is an error. If there is an error the tarball will NOT be formed by mkiocccentry; otherwise the txzchk(1) tool will be executed on the tarball.

    -

    When the Judges use chkentry(1) on your submission directory, +

    When the Judges use chksubmit(1) on your submission directory, if this JSON file is invalid JSON or does not match the requirements outlined above, or if any other is found, your submission WILL BE rejected.

    -

    An obvious example where chkentry would fail to validate .info.json is if +

    An obvious example where chksubmit would fail to validate .info.json is if there is a mismatch of type in the JSON file with what is expected, for instance, if in .info.json the no_comment that we chose to not comment on is not a string or is the wrong string. Another obvious example is when things are out of range (see above for list). Two more examples would be if a field is missing or if an unknown filed is in the file. In these cases (and any others -that must be established as valid by chkentry) your submission would be +that must be established as valid by chksubmit) your submission would be rejected for violating Rule 17 and in particular -because chkentry would not validate the .info.json file.

    +because chksubmit would not validate the .info.json file.

    If you wish to verify that your .info.json file is valid JSON then see the FAQ on “validating JSON documents”.

    Jump to: top

    -

    Q 3.6: What is an author_handle?

    +

    Q 3.5: What is an author_handle?

    An author_handle is string that refers to a given author and is unique to the IOCCC. Each author has exactly one author_handle.

    @@ -3106,7 +2662,7 @@ in the case of top

    -

    Q 3.7: What is an author_handle.json file and how are they used?

    +

    Q 3.6: What is an author_handle.json file and how are they used?

    TL:DR: The contents of these JSON files contain the best known @@ -3456,7 +3012,7 @@ for information about how to update and/or correct IOCCC author information.

    Jump to: top

    -

    Q 3.8: How can I find my author handle?

    +

    Q 3.7: How can I find my author handle?

    If you are an author of a winning entry, you may find your own author_handle by going to your entry in the authors.html web page and viewing the string @@ -3490,7 +3046,7 @@ for more information on terms such as author, entry, and s

    Jump to: top

    -

    Q 3.9: What is an entry_id?

    +

    Q 3.8: What is an entry_id?

    An entry_id is a string that identifies a winning entry of the IOCCC.

    An entry_id is a 4-digit year, followed by an underscore, followed by a directory name.

    @@ -3500,7 +3056,7 @@ of 2020 is found under the directory

    The entry_id for that winning entry is 2020_ferguson2.

    Jump to: top

    -

    Q 3.10: What is a .entry.json file and how is it used?

    +

    Q 3.9: What is a .entry.json file and how is it used?

    TL:DR: The contents of this JSON file contain information about each winning entry in JSON format.

    @@ -3917,7 +3473,7 @@ something along those lines.

    Jump to: top

    -

    Q 3.11: How can I validate any JSON document?

    +

    Q 3.10: How can I validate any JSON document?

    If you want or need to verify that a JSON document (as a string or file) is @@ -3948,7 +3504,7 @@ the tool.

    repo but we recommend you compile and install via the mkiocccentry repo because it has the dependencies built in, and because the mkiocccentry copy is that which is used by the current IOCCC, -as the two can be different at times.

    +as the two can sometimes be different.

    Jump to: top

    diff --git a/faq.md b/faq.md index e0cc469f6..48d857033 100644 --- a/faq.md +++ b/faq.md @@ -1,6 +1,6 @@ # IOCCC FAQ Table of Contents -This is FAQ version **28.2.22 2025-08-24**. +This is FAQ version **28.2.23 2025-11-17**. ## 0. [Entering the IOCCC: the bare minimum you need to know](#enter_questions) @@ -11,7 +11,6 @@ This is FAQ version **28.2.22 2025-08-24**. - **Q 0.1.3**: How do I compile the mkiocccentry toolkit? - **Q 0.1.4**: How do I install mkiocccentry(1) and related tools? - **Q 0.1.5**: How do I use mkiocccentry? - - **Q 0.1.6**: What are the minimum versions required for this contest? - **Q 0.2**: What platform should I assume for my submission? - **Q 0.3**: What should I put in my submission Makefile? - **Q 0.4**: What should I put in the remarks.md file of my submission? @@ -24,15 +23,14 @@ This is FAQ version **28.2.22 2025-08-24**. - **Q 1.1**: May I use a different source or compiled filename than prog.c or prog? - **Q 1.2**: What is markdown and how does the IOCCC use it? - **Q 1.3**: How do I report bugs in an `mkiocccentry` tool? -- **Q 1.4**: How may I use subdirectories in my submission if Rule 17 disallows them? -- **Q 1.5**: How can I check if my submission passes tests without having to answer questions? -- **Q 1.6**: What are extra files and how may I include additional files beyond the max allowed? -- **Q 1.7**: May I use AI, LLM, Virtual coding assistants, or similar tools to write my submission? -- **Q 1.8**: What are the details behind Rule 17? -- **Q 1.9**: How can I avoid re-entering my UUID to mkiocccentry? -- **Q 1.10**: How can I avoid having to move or delete my submission directory for the same workdir? -- **Q 1.11**: Can I download my submission tarball from the submit server? -- **Q 1.12**: Can I delete a submission from the submit server? +- **Q 1.4**: How can I check if my submission passes tests without having to answer questions? +- **Q 1.5**: What are extra files and how may I include additional files beyond the max allowed? +- **Q 1.6**: May I use AI, LLM, Virtual coding assistants, or similar tools to write my submission? +- **Q 1.7**: What are the details behind Rule 17? +- **Q 1.8**: How can I avoid re-entering my UUID to mkiocccentry? +- **Q 1.9**: How can I avoid having to move or delete my submission directory for the same workdir? +- **Q 1.10**: Can I download my submission tarball from the submit server? +- **Q 1.11**: Can I delete a submission from the submit server? ## 2. [IOCCC Judging process](#judging_process) @@ -50,18 +48,17 @@ This is FAQ version **28.2.22 2025-08-24**. ## 3. [The mkiocccentry toolkit: finer details](#mkiocccentry_details) -- **Q 3.0**: What is the `mkiocccentry(1)` process and what sort of checks does it perform? -- **Q 3.1**: How can I validate my submission tarball? -- **Q 3.2**: What is the `fnamchk` tool? -- **Q 3.3**: How can I validate my submission directory? -- **Q 3.4**: What is a `.auth.json` file? -- **Q 3.5**: What is a `.info.json` file? -- **Q 3.6**: What is an `author handle`? -- **Q 3.7**: What is an `author_handle.json` file and how are they used? -- **Q 3.8**: How can I find my author handle? -- **Q 3.9**: What is an `entry_id`? -- **Q 3.10**: What is a `.entry.json` file and how is it used? -- **Q 3.11**: How can I validate any JSON document? +- **Q 3.0**: How can I validate my submission tarball? +- **Q 3.1**: What is the `fnamchk` tool? +- **Q 3.2**: How can I validate my submission directory? +- **Q 3.3**: What is a `.auth.json` file? +- **Q 3.4**: What is a `.info.json` file? +- **Q 3.5**: What is an `author handle`? +- **Q 3.6**: What is an `author_handle.json` file and how are they used? +- **Q 3.7**: How can I find my author handle? +- **Q 3.8**: What is an `entry_id`? +- **Q 3.9**: What is a `.entry.json` file and how is it used? +- **Q 3.10**: How can I validate any JSON document? ## 4. [Compiling IOCCC entries](#compiling) @@ -247,7 +244,7 @@ looking for mismatches. If no errors are detected it will list everything to you again, asking you to confirm it is good. If everything is OK, it will write the required `.auth.json` and `.info.json` -and then run `chkentry(1)` on the directory. If all is OK it will create the +and then run `chksubmit(1)` on the directory. If all is OK it will create the tarball. After the tarball is formed, it will run `txzchk(1)` on it, which runs `fnamchk(1)`. If all is OK, your submission tarball should be good to go. @@ -256,7 +253,7 @@ FAQ on "[txzchk](#txzchk)", the FAQ on "[fnamchk](#fnamchk)" and the -FAQ on "[chkentry](#chkentry)" +FAQ on "[chksubmit](#chksubmit)" for more information on these important tools, if you want more information. See the @@ -342,12 +339,13 @@ above) run as either `sudo(8)` or root `make install`: ``` If everything goes well you should be able to run `mkiocccentry(1)`, -`txzchk(1)`, `chkentry(1)` and all the other installed tools from any directory, +`txzchk(1)`, `chksubmit(1)` and all the other installed tools from any directory, and the tools that rely on other tools will be able to find those required tools from any directory too. Some tools like `bug_report.sh` and `hostchk.sh` are not meant to be installed -and will not work from any directory, however. +and will not work from any directory, however, nor should they be installed +(some previously were but this was fixed post IOCCC28 and prior to IOCCC29). Jump to: [top](#) @@ -410,35 +408,13 @@ looked at if the submission wins), run some tests and run a number of other tools, as mentioned above, and as described in the "[finer details](#mkiocccentry_details)" section. -See also the -FAQ on "[what the minimum required versions are for this -contest](#minimum_versions)" -for more details on how to verify you have the correct versions for this -contest. +**PLEASE NOTE**: if your submission directory (or topdir) has certain errors the +mkiocccentry tool will exit with a fatal error, asking you to fix the problem +first. Jump to: [top](#) - -
    -#### Q 0.1.6: What are the minimum versions required for this contest? -
    - -At minimum, the tools **MUST** be version: - -- `iocccsize(1)`: `"28.15 2024-06-27"`. -- `mkiocccentry(1)`: `"2.0.1 2025-03-02"`. -- `fnamchk(1)`: `"2.0.0 2025-02-28"`. -- `txzchk(1)`: `"2.0.1 2025-03-02"`. -- `chkentry(1)`: `"2.0.1 2025-03-02"`. - -See also the -FAQ on "[obtaining the latest release of the toolkit](#obtaining_mkiocccentry)". - - -Jump to: [top](#) - -
    @@ -645,7 +621,7 @@ Jump to: [top](#) Files in your submission tarball **MUST** be specific permissions. In particular: directories **MUST** be `drwxr-xr-x` (i.e. -`0755`), the optional files, `try.sh` or `try.alt.sh`, if provided, **MUST** be +`0755`), the optional files, files ending with `.sh`, if provided, **MUST** be `-r-xr-xr-x` (i.e. `0555`) and all other files **MUST** be `-r--r--r--` (i.e. `0444`). @@ -806,28 +782,8 @@ for more thorough details on bug reporting. Jump to: [top](#) - -
    -#### Q 1.4: How may I use subdirectories in my submission if Rule 17 disallows them? -
    - -In order to submit a subdirectory, you may simply include a tarball. As long as -the maximum depth of all files does not exceed the maximum, defined as -`MAX_PATH_DEPTH`, the maximum filename length (a single component not counting -the `/`) of all files does not exceed `MAX_FILENAME_LEN` and -the maximum path length (all components) of all files does not exceed -`MAX_PATH_LEN`. These macros are defined in -[limit_ioccc.h](https://github.com/ioccc-src/mkiocccentry/blob/master/soup/limit_ioccc.h). - - -See also the -FAQ on "[Rule 17](#rule17)", -the [guidelines](next/guidelines.html) and [Rule 17](next/rules.html#rule17) -itself. - -
    -#### Q 1.5: How can I check if my submission passes tests without having to answer questions? +#### Q 1.4: How can I check if my submission passes tests without having to answer questions?
    In case you do not have a UUID or you simply want to test if `mkiocccentry(1)` @@ -847,7 +803,7 @@ An example use of this option is: ``` This will run the tests that `mkiocccentry(1)`, write the JSON files, use -`chkentry(1)`, package the tarball and run `txzchk(1)` on it. +`chksubmit(1)`, package the tarball and run `txzchk(1)` on it. If you don't want to deal with the having to move or delete the submission directory, you could instead do: @@ -865,7 +821,7 @@ FAQ on "[.info.json](#info_json)", the FAQ on "[.auth.json](#auth_json)", the -FAQ on "[chkentry](#chkentry), +FAQ on "[chksubmit](#chksubmit), the FAQ on "[txzchk](#txzchk)" and the @@ -874,32 +830,28 @@ for more details.
    -# What are extra files and how may I include additional files beyond the max allowed? +# 1.5: What are extra files and how may I include additional files beyond the max allowed?
    -

    -Extra files are defined as files that are not the required files (`prog.c`, -`Makefile`, `remarks.md` and the two generated by `mkiocccentry(1)` `.info.json` -and `.auth.json`) and files that are also not the optional files (`try.sh`, -`prog.alt.c` and `try.alt.sh`). -

    +Extra files are defined as files that are not the free files (the required files +`prog.c`, `Makefile`, `remarks.md` and the optional `try.sh`, `try.alt.sh`, +`prog.alt.c` and the two generated by `mkiocccentry(1)` `.info.json` and +`.auth.json`). -

    **NOTE**: optional filenames are only optional if they are in the submission top level directory. -

    -

    +You may provide up to 31 extra files. + If you need to include more files than this, you may include a tarball that itself is an extra file, meaning it counts **AS** an extra file. This file does **NOT** need to pass the `txzchk(1)` tests; only your submission -tarball needs to pass these tests. -

    +tarball needs to pass these tests. However see below if you do do this. Please pay careful attention to [Rule 17](next/rules.html#rule17) and in -particular the part about the [maximum number of files per -submission](#max-files), which not only discusses the maximum -number of files (including extra files) but also specific rules you must follow +particular the part about the maximum number of files per +submission, which not only discusses the maximum +number of files but also specific rules you must follow if you do include a tarball. Not following these points puts you at great risk of violating [Rule 17](next/rules.html#rule17)! @@ -921,7 +873,7 @@ Jump to: [top](#)
    -### Q 1.7: May I use AI, LLM, Virtual coding assistants, or similar tools to write my submission? +### Q 1.6: May I use AI, LLM, Virtual coding assistants, or similar tools to write my submission?
    @@ -940,87 +892,79 @@ Jump to: [top](#)
    -### Q 1.8: What are details behind Rule 17? +### Q 1.7: What are details behind Rule 17?
    ### TL;DR Rule 17 - Use `mkiocccentry(1)` -

    -This is a **COMPLEX** rule. **Violating this rule will cause your submission to -be REJECTED!** To help you avoid such a rejection, you are **HIGHLY ENCOURAGED** +This is a **COMPLEX** rule. **Violating this rule WILL CAUSE YOUR SUBMISSION TO +BE REJECTED!** To help you avoid such a rejection, you are **HIGHLY ENCOURAGED** to use the `mkiocccentry(1)` tool, based on the latest release of the [mkiocccentry repo](https://github.com/ioccc-src/mkiocccentry), to form your submission's xz compressed tarball. -

    -

    The [mkiocccentry repo](https://github.com/ioccc-src/mkiocccentry) contains **IMPORTANT** tools and libraries such as: -

    -*

    `mkiocccentry(1)`

    -*

    `iocccsize(1)`

    -*

    `txzchk(1)`

    -*

    `fnamchk(1)`

    -*

    `jparse(3)`

    -*

    `chkentry(1)` (which uses `jparse(3)`)

    +- `mkiocccentry(1)` +- `iocccsize(1)` +- `txzchk(1)` +- `fnamchk(1)` +- `jparse(3)` +- `chksubmit(1)` (which uses `jparse(3)` and is a wrapper to `chkentry(1)`) -

    The above mentioned tools will help you verify that your submission conforms to [Rule 17](next/rules.html#rule17). Each of these tool has a `-h` option that provides command line help. For additional details of each tool, see its man page, and in some cases, the [IOCCC guidelines](next/guidelines.html). -

    -

    -The maximum number of **extra files** is 31. See the [maximum number of extra -files section](#max-files) below for finer details and the -FAQ on "[what extra files are and how to include additional files](#extra-files)", -should you need to include more files than this maximum. -

    +The maximum number of **extra files** is 31. See the +FAQ on "[extra files](#extra-files)" +for more details. +Below we will list more details and link to relevant FAQs as well. Jump to: [top](#) ### Rule 17 - The COMPLEX details -

    Each submission **MUST** be in the form of an xz compressed tarball. The xz compressed tarball filename **MUST** be of the form: `^submit.username-slot_num.[1-9][0-9]{9,}.txz$`. -

    ... where _`username`_ is your IOCCC registration username **in the form of a [UUID](https://en.wikipedia.org/wiki/Universally_unique_identifier)** (see [RFC 9562](https://datatracker.ietf.org/doc/html/rfc9562) for details), and where _`slot_num`_ is a single decimal digit integer (i.e., >= `0` and <= `9`). -

    -

    In particular, `username` is in the form of: `xxxxxxxx-xxxx-4xxx-Nxxx-xxxxxxxxxxxx` where `'x'` is a hex digit in the range of `[0-9a-f]`, 4 is the UUID version, and `N` is one of `8`, `9`, `a`, or `b`. -

    -

    Your xz compressed tarball **MUST** contain, **at a minimum**, the following -files, in the **TOP LEVEL** directory: -

    +files, in the **TOP LEVEL** directory (see below for more details on each file +in this list): -*

    `prog.c`

    -*

    `Makefile`

    -*

    `remarks.md`

    -*

    `.auth.json`

    -*

    `.info.json`

    +- `prog.c`: your submission code. +- `Makefile`: your Makefile that is based on +[next/Makefile.example](next/Makefile.example). +- `remarks.md`: your remarks about the submission in markdown format. +- `.auth.json`: a JSON file about the author details (which will only be looked at by +the judges IF it wins), generated by the `mkiocccentry(1)` tool. +- `.info.json`: a JSON file about the submission itself which will be looked at +by the judges during judging. -

    -`prog.c` is of course your submission program. -

    +Note that these do not count against extra files. Neither do the `try.sh`, +`prog.alt.c` or `try.alt.sh`, should you provide them, and they are in the top +level directory. See the +FAQ on "[extra files](#extra-files)" +for more details on what this means, should you need to include additional files. + +The `prog.c` is probably pretty obvious if you're here. :-) -

    The `Makefile` **MUST** be a **non**-empty file in **[GNU Makefile](https://www.gnu.org/software/make/manual/make.html)** format. See the [Makefile section in the guidelines](next/guidelines.html#makefile), @@ -1029,9 +973,7 @@ FAQ on "[submission Makefiles](#submission_makefile)" and the FAQ on "[IOCCC make(1) compatibility](#make_compatibility)" for help. -

    -

    The `remarks.md` **MUST** be a **non**-empty file in markdown format (`mkiocccentry(1)` only checks the file size but if you do not have any text in it you still risk violating this rule). See also @@ -1040,225 +982,174 @@ FAQ on "[remarks.md](#remarks_md)", our FAQ on "[markdown](#markdown)" and our [markdown guidelines](markdown.html). -

    -

    See also the [markdown syntax](https://www.markdownguide.org/basic-syntax) guide and the [CommonMark Spec](https://spec.commonmark.org/current/). -

    -

    The `.auth.json` file is created by `mkiocccentry(1)` and it holds information about the author(s) of the submission. It will **ONLY** be looked at if your submission wins but it **MUST** still be valid according to `jparse(3)` **AND** -`chkentry(1)`. -

    +`chksubmit(1)` even if it does not win; if `chksubmit(1)` does not validate this +file your submission **WILL** be rejected for violating Rule 17! See the +FAQ on "[.auth.json](#auth.json)" +for more details on this file. -

    The `.info.json` file is created by `mkiocccentry(1)` and it holds information about the submission itself. It also **MUST** be valid according to **BOTH** -`jparse(3)` **AND** `chkentry(1)`. -

    +`jparse(3)` **AND** `chksubmit(1)`. See the +FAQ on "[.info.json](#info.json)" +for more details on this file. + +See the +FAQ on "[chksubmit(1)](#chksubmit)" +for more details on this important tool. -

    For the complete `mkiocccentry(1)` process, see the FAQ on the "[mkiocccentry process](#mkiocccentry_process)". -

    -

    The tool performs a lot of checks, both directly and indirectly, and if it or any other tool detects **ANY** problem, you are **HIGHLY** encouraged to fix it and try again. -

    -

    On the other hand, some issues are errors and you **MUST** fix those. -

    -

    -If you do use `mkiocccentry(1)` and you run into a problem, you might see the -FAQ on "[how to ask a question about the IOCCC rules, guidelines and -tools](#questions)". -If you believe you have encountered a bug, feel free to open a bug report at the -[mkiocccentry repo issues +If you do use `mkiocccentry(1)` (which we STRONGLY recommend you do) and you run +into a problem, you might see the FAQ on "[how to ask a question about the IOCCC +rules, guidelines and tools](#questions)". If you believe you have encountered +a bug, feel free to open a bug report at the [mkiocccentry repo issues page](https://github.com/ioccc-src/mkiocccentry/issues/new?assignees=&labels=bug&projects=&template=bug_report.yml&title=%5BBug%5D+%3Ctitle%3E). -

    -

    The xz compressed tarball file **MUST** be <= **3999971** octets in size. -

    -

    When your submission's xz compressed tarball is uncompressed, the total size of your submission (the sum of the size of the program source code, remarks/comments, Makefile and all other files) **MUST** be <= **28314624** octets (**27651K**) in size. -

    -

    One of the many checks `txzchk(1)` performs is summing up the total size. Of course if you manipulate the tarball to get past this you risk violating this rule. -

    -

    Your submission's xz compressed tarball **MUST** pass the `txzchk(1)` tests. See the [guidelines on txzchk(1)](next/guidelines.html#txzchk) for more details on this tool. -

    -

    -**IMPORTANT**: Make **SURE** you have the most recent version of the +**IMPORTANT**: make **SURE** you have the most recent version of the `mkiocccentry` toolkit! Not doing so will put you at a great risk of violating this rule! See the FAQs on "[obtaining, compiling, installing and using the mkiocccentry toolkit](#mkiocccentry)" for more details. -

    -

    You are **HIGHLY ENCOURAGED** to use the `mkiocccentry(1)` tool to form your submission's xz compressed tarball. See the [guidelines on mkiocccentry(1)](next/guidelines.html#mkiocccentry) for more details on this tool and see the [mkiocccentry repo](https://github.com/ioccc-src/mkiocccentry) for the toolkit itself. -

    -

    -Your entry **MAY** have subdirectories, depending on the depth and total length of -the filenames. Certain directories like `.git`, `RCCS`, `CVS` and `.svn` -(amongst others) are skipped. For more information, see the +Your entry **MAY** have subdirectories, depending on the depth (a max depth, +noted below) and total length of the filenames. Certain directories like `.git`, +`RCCS`, `CVS` and `.svn` (amongst others) are skipped. For more information, see +the FAQ on "[subdirectories](#subdirectories)". -

    -

    With the exception of those generated by the `mkiocccentry(1)` tool or the tools it or any other tool invokes, files in your submission **MUST**: -

    -*

    Be <= **38** characters in length.

    -*

    **NOT** have a leading **`/`**.

    -*

    **NOT** contain a path component of: **`.`** (that is, with +- Be <= **38** characters in length. +- **NOT** have a leading **`/`**. +- **NOT** contain a path component of: **`.`** (that is, with the exception of files generated by `mkiocccentry(1)` itself, it must have -**NO** dot file including `.` itself).

    -*

    **NOT** contain a path component of: **`..`** (that is, -**NO** path component that matches the regular expression **`^..$`**).

    -*

    Match the regular expression +**NO** dot file including `.` itself). +- **NOT** contain a path component of: **`..`** (that is, +**NO** path component that matches the regular expression **`^..$`**). +- Match the regular expression `^[0-9A-Za-z]+[0-9A-Za-z_+.-]*$` (again, excluding files generated by -`mkiocccentry(1)`).

    -*

    **NOT** have a directory/file depth > 4.

    -*

    **NOT** have a total **path** length > 99 characters.

    +`mkiocccentry(1)`). +- **NOT** have a directory/file depth > 4. +- **NOT** have a total **path** length > 99 characters. -

    -The submission tarball created by `mkiocccentry(1)` **MUST** have -the additional files that are generated by the `mkiocccentry(1)` tool: -

    +Again, the submission tarball **MUST** have the mkiocccentry(1) created JSON +files: -*

    `.auth.json` which contains information about the author or +- `.auth.json` which contains information about the author or authors (that will only be looked at if the submission wins).

    -*

    `.info.json` which contains information about the +- `.info.json` which contains information about the submission.

    -

    -The `chkentry(1)` tool will validate these two JSON files, and do other checks +The `chksubmit(1)` tool will validate these two JSON files, and do other checks on your submission directory as well, _prior to_ `mkiocccentry(1)` forming the -tarball. -

    +tarball. See the +FAQ on "[chksubmit(1)](#chksubmit)" +for more details on this tool. -

    Files and directories in your submission tarball **MUST** be specific permissions and `mkiocccentry(1)` does this for you. In particular: directories -**MUST** be `drwxr-xr-x` (i.e. `0755`); the optional files, not counting -`prog.alt.c` (i.e. `try.sh` and `try.alt.sh`), if provided, **MUST** be +**MUST** be `drwxr-xr-x` (i.e. `0755`); any file ending with `.sh` **MUST** be `-r-xr-xr-x` (i.e. `0555`); and all other files **MUST** be `-r--r--r--` (i.e. -`0444`). If any file or directory does not have the correct permissions, your submission **WILL** -be rejected for violating [Rule 17](next/rules.html#rule17)! -

    +`0444`). If any file or directory does not have the correct permissions, your +submission **WILL** be rejected for violating [Rule 17](next/rules.html#rule17)! -

    After `mkiocccentry(1)` creates the directories and copies the files with these modes, it also verifies them after the fact and if they are not correct it is an **error**. -

    -

    If you do need different permissions, then see the FAQ on "[file permissions](#file_perms)". Also keep in mind [Rule 4](next/rules.html#rule4), [Rule 5](next/rules.html#rule5) and [Rule 21](next/rules.html#rule21). -

    -

    The `txzchk(1)` tool will also verify file/directory permissions (and many other -things) for you, and so will `chkentry(1)` (along with other checks on files and +things) for you, and so will `chksubmit(1)` (along with other checks on files and directories in your submission directory, including the two required JSON files, `.auth.json` and `.info.json`). If these checks fail it is an **error** and `mkiocccentry(1)` will abort. In this case (it fails and you used `mkiocccentry(1)`) it is very **possibly** a bug; please [report it as a bug at the mkiocccentry issues page](https://github.com/ioccc-src/mkiocccentry/issues/new?assignees=&labels=bug&projects=&template=bug_report.yml&title=%5BBug%5D+%3Ctitle%3E). -

    -

    The tarball filename **MUST** pass `fnamchk(1)`; the tool `txzchk(1)` will run `fnamchk(1)` as part of its algorithm. If you use `mkiocccentry(1)` there should be no problem but if you were to package things manually it is possible there could be a problem and this poses a big risk of violating [Rule 17](next/rules.html#rule17). -

    -

    The `fnamchk(1)`, which `txzchk(1)` executes, will verify that the filename is correct. But if you do package your tarball manually, and you have a mismatch in what is in the tarball and the name, `txzchk(1)` will flag the discrepancy as an error and exit with non-zero. -

    -

    These checks **MUST PASS**. If they do not you stand a significant chance of having your submission rejected for violating [Rule 17](next/rules.html#rule17)! -

    -
    #### Maximum number of files per submission
    -

    The maximum number of files your submission tarball may contain, not counting -the optional files (`prog.alt.c`, `try.sh`, `try.alt.sh`) and the mandatory -files (`prog.c`, `Makefile`, `remarks.md` plus the `mkiocccentry(1)` generated -files `.auth.json` and `.info.json`), is 31. This is defined in the macro +the free files (`prog.c`, `remarks.md`, `Makefile`, `prog.alt.c`, `try.sh`, +`try.alt.sh`,, `.info.json` and `.auth.json`) is 31. This is defined in the macro `MAX_EXTRA_FILE_COUNT` in [soup/limit_ioccc.h](https://github.com/ioccc-src/mkiocccentry/blob/master/soup/limit_ioccc.h) in the [mkiocccentry repo](https://github.com/ioccc-src/mkiocccentry). See the FAQ on "[what extra files are and how to include more](#extra-files)" if you need to include more files. -

    -

    If you do include a tarball that takes your extra files count over the maximum, you **MUST** explain this in your `remarks.md` file! **PLEASE** do not include a tarball with extra files for a test-suite; instead mention in your remarks that you have extra files for a test-suite that can be included should your submission win. Of course if you don't need that many files for a test-suite you are more than welcome to include those files in your submission. -

    -

    If you need to extract a tarball by some Makefile, or perhaps the program itself, then `make clobber` **MUST** remove everything that the extraction created! -

    -

    Tarballs **MUST** only create files and directories _under_ the submission directory. They may **NOT** contain absolute paths (paths that start with `/`)! `txzchk` does **NOT** check other tarballs so **YOU MUST** verify these details yourself. -

    -

    **IMPORTANT REMINDER**: **MAKE SURE** your tarball does not reveal who you are! The `mkiocccentry(1)` tool uses the v7 format. For instance you might try: -

    ``` tar --format=v7 -cJf foo.txz directory @@ -1266,32 +1157,24 @@ The `mkiocccentry(1)` tool uses the v7 format. For instance you might try:
    - -

    **IMPORTANT**: where [Rule 17](next/rules.html#rule17) and the tools from the latest release of the [mkiocccentry repo](https://github.com/ioccc-src/mkiocccentry) conflict, the [IOCCC judges](judges.html) will use their best judgment which is likely to favor [mkiocccentry repo](https://github.com/ioccc-src/mkiocccentry) code. -

    -

    This means you should **MAKE SURE** that you use `mkiocccentry(1)` to package your submission; `mkiocccentry(1)` will run the above mentioned tools (that do not act on the tarball) **before** creating the tarball and after the tarball is created it will then verify that the tarball is okay by running `txzchk(1)` on it. If any step fails it is an error and submitting the submission will result in violating this rule. -

    -

    **MAKE SURE** you use the correct release of the repository; you should do this **AFTER** the contest opens (pull any changes or if you prefer download the repository via the download option at GitHub). See the FAQ on "[obtaining the latest release of mkiocccentry](#obtaining_mkiocccentry)" for more help on ensuring you do have the most up to date release. -

    -

    We recommend that you run `make` and then install the tools (and man pages) via `make install` (as root or using `sudo(8)`) to help you run these tools from your submission's directory (or any other directory). The `make install` will @@ -1299,32 +1182,27 @@ install in `/usr/local`. However, **you do not have** to install them, but in that case you'll have to run it from the toolkit's directory or use the correct options to specify the path to the necessary tools, and also specify the path to your files, which can be problematic. -

    -

    These tools will link in the `jparse(3)` library, the `dbg` library and the -`dyn_array` library; `chkentry(1)` uses the JSON parser (`jparse(3)`) to -validate and parse the [JSON](https://www.json.org/json-en.html) files but the -other tools use parts of the `jparse` utility functions as well. -

    +`dyn_array` library as well as the `pr(3)` and `soup(3)` libraries; +`chksubmit(1)` uses the JSON parser (`jparse(3)`) to validate and parse the +[JSON](https://www.json.org/json-en.html) files but the other tools use parts of +the `jparse` utility functions as well. -

    If you run into a problem with one or more of these tools, **PLEASE** [report it as a bug at the mkiocccentry issues page](https://github.com/ioccc-src/mkiocccentry/issues/new?assignees=&labels=bug&projects=&template=bug_report.yml&title=%5BBug%5D+%3Ctitle%3E), **making sure to run `bug_report.sh`**. See the [guidelines](next/guidelines.html) for help here and also read our FAQ on "[mkiocccentry repo bugs](#mkiocccentry_bugs)". -

    -

    At the risk of stating the obvious: submissions that violate [Rule +At the risk of stating the obvious: submissions that violate [Rule 17](next/rules.html#rule17) **WILL BE REJECTED**, so **BE SURE** to use the latest release of the [mkiocccentry repo](https://github.com/ioccc-src/mkiocccentry), to form and test your submission's xz compressed tarball. Do **NOT** assume you have the most recent release without pulling or downloading via GitHub and do **MAKE SURE** you do this **AFTER** the [contest status](status.html) has changed to [open](#open). -

    Jump to: [top](#) @@ -1332,7 +1210,7 @@ Jump to: [top](#)
    -### Q 1.9: How can I avoid re-entering my UUID to mkiocccentry? +### Q 1.8: How can I avoid re-entering my UUID to mkiocccentry?
    @@ -1368,7 +1246,7 @@ FAQ on "[the answers file](#answers_file)". Jump to: [top](#)
    -### Q 1.10: How can I avoid having to move or delete my submission directory for the same workdir? +### Q 1.9: How can I avoid having to move or delete my submission directory for the same workdir?
    If you wish to not have to worry about removing or moving the submission @@ -1389,7 +1267,7 @@ specify the path by the `-r rm` option. Jump to: [top](#)
    -### Q 1.11: Can I download my submission tarball from the submit server? +### Q 1.10: Can I download my submission tarball from the submit server?
    We do not support this. If you need to verify your submission, then @@ -1871,306 +1749,10 @@ Jump to: [top](#) Jump to: [top](#) -
    -### Q 3.0: What is the `mkiocccentry(1)` process and what sort of checks does it perform? -
    - -**TL;DR**: the program will make a submission directory (name based on the -username and slot number you provide) under the workdir and then switch to the -topdir. It will then create lists of files and directories to present to you, to -verify everything is in order. If something is not allowed (bad filename for -example) or an error occurs (missing required file for example) you will be -notified of this. After you verify everything is okay the files/directories -found will be copied/made and it will then switch to the submission directory. -In the submission directory it first runs `make clobber` and then scans the -directory hierarchy again, verifying things are still okay. When done it will -ask you to verify things still look OK to you too. If all is good it'll ask you -for more information about the author(s). Next the two required JSON files -`.auth.json` and `.info.json` will be created. After that `chkentry(1)` will be -run on the directory. If all is good it'll give you another chance to say the -files/directories look good and if you answer yes it'll create the tarball and -run `txzchk` on it. - -In most cases the program will prompt you to verify your input is correct. In -the case of author information (which will only be looked at if you win) you -will be asked to verify country code prior to being asked the other questions. -If you fail to enter other author information correctly you will be prompted -right away to fix it. Afterwards, when the author information is collected, it -will ask you to confirm. This procedure happens for each author. - -In the case of `-i answers` option being used, you will not have to put in most -information but you will have to confirm the lists of files and directories are -correct, unless you use `-Y` (which we do not recommend). - -If `topdir` is not a readable (`+r`), searchable (`+x`) directory it is an error. - -If `workdir` is not a writable (`+w`), searchable (`+x`) directory it is an error. - -If `workdir` is in `topdir` the program will not descend into it (the workdir). - -If `topdir` is the same (by device and inode) as `workdir` it is an error. -If somehow `topdir` or `workdir` is found under the submission directory (by -device and inode) it is an error (and you should report it as a bug. - -In more detail the `mkiocccentry(1)` tool performs the below steps. - -0. Ask the user for a submission ID (see the [how to register](next/register.html) -for more details on how to obtain this and [Rule 17](next/rules.html#rule17) for -the importance of this). - * If this is an invalid UUID (malformed), you will be asked to correct it - until it is. - * If the `-u uuidfile` option is used and the UUID in the file `uuidfile` is not malformed, - the user will not be prompted for a UUID. - * If the `-U uuidstr` option is used and the UUID is not malformed, the user - will not be prompted for a UUID. - * The `-u` and `-U` options may not be used with any option that reads from - an answers file (`-i answers`, `-d`, `-s seed`). -1. Ask the user for the submission slot (the submission number; see [how to -register](next/register.html) and [Rule 17](next/rules.html#rule17) for more details). - * If this is out of range (see `MAX_SUBMIT_SLOT` in - [limit_ioccc.h](https://github.com/ioccc-src/mkiocccentry/blob/master/soup/limit_ioccc.h)) - you will be asked to correct it until it is. -2. Make the submission directory under `topdir` in the form of -`workdir/submit.USERNAME-SLOT`. - * If this directory already exists it is an error, unless the `-x` option is - used, in which case it'll be deleted. - * If for some reason the default `rm` paths do not work, you may use `-r rm` - to specify the path to a working `rm` command. -3. Change to the `topdir`. -4. Traverse the directory, creating lists of ignored/forbidden -files/directories/symlinks as well as a list directories to make and a list of -files to copy to the submission directory (and if (sub)directories are found -with files, copy those files to their respective directory). Note the following: - * If the depth is too deep it is an error (see `MAX_PATH_DEPTH` in - [limit_ioccc.h](https://github.com/ioccc-src/mkiocccentry/blob/master/soup/limit_ioccc.h)). - * If there are too many extra directories (total count not including the - submission directory itself, unrelated to `MAX_PATH_DEPTH` above) it is an - error (see `MAX_EXTRA_DIR_COUNT` in - [limit_ioccc.h](https://github.com/ioccc-src/mkiocccentry/blob/master/soup/limit_ioccc.h)). - * If the max path length is <= 0 it is an error (and a bug!). - * If the max depth is <= 0 it is an error (and a bug!). - * If the max filename length is <= 0 it is an error (and a bug!). - * If a path is NULL it is an error. - * If a path is an empty string it is an error. - * If the path length (i.e. `strlen(path)` where path starts after the - initial `./` of the path in the `topdir`) is too long it is an error (see `MAX_PATH_LEN` in - [limit_ioccc.h](https://github.com/ioccc-src/mkiocccentry/blob/master/soup/limit_ioccc.h)). - * If a filename (last component of the path) is too long it is an error (see `MAX_FILENAME_LEN` in - [limit_ioccc.h](https://github.com/ioccc-src/mkiocccentry/blob/master/soup/limit_ioccc.h)). - * If a filename or directory name is not a sane relative path, not allowed - or will not be added for some other reason, it will be added to a relevant list to show to - the user later, to let them know it will not be added to the submission. By `relative` we mean it - must not start with `/` (which shouldn't happen even if you give an absolute - path) and by `sane` we mean that each component must match the regexp: `^[0-9A-Za-z]+[0-9A-Za-z_+.-]*$`. - * If a directory is unreadable it is an error. - * If a directory causes a cycle in the tree it is an error. - * If `stat(2)` on the path fails it is an error. - * If `prog.c`, `Makefile` or `remarks.md` is/are not found it is an error. - * If too many files that are not `prog.c`, `Makefile`, `remarks.md`, - `try.sh`, `prog.alt.c` or `try.alt.sh` are found, it is an error (see - `MAX_EXTRA_FILE_COUNT` in - [limit_ioccc.h](https://github.com/ioccc-src/mkiocccentry/blob/master/soup/limit_ioccc.h)). - * Symlinks are not allowed but it is not an error (they will be added to a - list and ignored). - * If any file type other than a regular file, a directory or a symlink is - encountered it is an error. - * If there is an unknown error it is an error :-) -5. Show each list to the user, asking if this is okay. The lists include: - * Ignored directories (those like `.git`, `CVS`, `RCCS`, `.svn` and various - others). - * Unsafe directory names that will not be added (i.e. those that are not - POSIX plus + safe chars only; see above step (4)). This includes directories - starting with a `.`. - * Forbidden files such as `index.html`, `README.md`, `prog`, `prog.alt`. - * Unsafe filenames that will not be added (i.e. those that are not POSIX - plus + safe chars only; see above step (4)). This includes files starting - with `.`. - * Symlinks found (these are not allowed). - * Directories to be made. - * Required files (`prog.c`, `Makefile` and `remarks.md`) to be copied. - * Non-required files to be copied. - * The user is asked to verify each list, including the lists of directories - and files to be made/copied, and if the user says it is not OK the program will abort. -6. Make any directories if necessary (under -`workdir/submit.USERNAME-SLOT` i.e. the submission directory). - * Directories **MUST** be and are made with mode `0755`. - * If any directory is not this mode `txzchk(1)` will flag it (and so will - `mkiocccentry(1)`). -7. The non-ignored files are copied to their respective directories under the -submission directory. - * `try.sh` and `try.alt.sh` **MUST** be and are copied as mode `0555`. - * All other files **MUST** be and are copied as mode `0444`. - * Anything else will be flagged by `txzchk(1)` (and it'll be flagged by - `mkiocccentry(1)` too). -8. `cd submit.USERNAME-SLOT` (i.e. switch to submission directory). -9. `make -f Makefile clobber`. - * If this fails it is not an error but you are warned about it (it is an error only if the `Makefile` - does not a regular readable file but; even so, see [Rule 20](next/rules.html#rule20). -10. Traverse the new tree from `.` (the submission directory) with additional steps from (4). - * If any file has an ignored directory name in it, it is an error. - * If a symlink is found it is an error. - * If any file type other than a directory or regular file exists it is an - error. - * If a forbidden filename exists it is an error. - * If any file or directory starts with `/` or is not POSIX plus + safe chars - only (see (4) above) it is an error (though this should not actually happen - unless you're doing something funny). - * If the directory depth becomes too deep it is an error. - * If `prog.c`, `Makefile` or `remarks.md` are missing (or not readable - regular files) it is an error. - * If an optional file is a directory it is an error. - * If a file or directory is in the submission directory that was not found - in the topdir it is an error. - * If a file or directory found in the topdir is not in the submission - directory it is an error. - * If a file or directory in the submission directory is a different type - from the topdir (e.g. if `foo` was a directory in topdir but in the submission - directory it is a file) it is an error. - * If a file (based on the name) or directory has the wrong permission it is - an error (see (7) above). - * If `fts_read(3)` reports something as a directory but it's not a directory - it is an error (and likewise if it reports something as a file and it's not - a file it is an error) - though this should never happen. - * If a directory name (full path from the submission directory) is the name - of a mandatory file it is an error. - * If a directory name (full path from the submission directory) is the name - of of an optional file it is an error. - * `iocccsize(1)` (via the `mkiocccentry(1)` function `check_prog_c()`) will - be run on your `prog.c`, allowing you to override any warnings; if you do not - override an issue flagged it is an error but if warnings from `check_prog_c()` - are ignored you risk violating the [Rules](next/rules.html), including [Rule - 2](next/rules.html#rule2). - * `check_Makefile()` will be run on `Makefile`; if it is a non-readable or - empty file it is an error but otherwise you may override any warnings - (risking violating the [Rules](next/rules.html), especially [Rule - 17](next/rules.html#rule17) and [Rule 20](next/rules.html#rule20)). - * `check_remarks_md()` will be run on your `remarks.m`; if it is not a - regular readable file or it is empty it is an error. Otherwise it will - proceed. Note it does not check that there is any text in the file, just - that the file size is not 0, and having a `remarks.md` that is not size 0 - but has no content is violating [Rule 17](next/rules.html#rule17) and [Rule - 19](next/rules.html#rule19). - * If any other error condition from step (4) occurs it is also an error. -11. Present the list of non-dot files that remain and ask the user to confirm. -12. Ask the user for a submission title. -13. Ask the user for a one line abstract of the submission. -14. Ask the user for the number of authors and for each author ask a variety of -questions (see below for more information on what kind of questions). -15. Create `.info.json`. -16. Create `.auth.json`. -17. Run `chkentry(1)` on your submission directory to verify things look good, -including that the `.info.json` and `.auth.json` files are okay. - * It also checks that the manifest in `.info.json` matches what is in the - submission directory and it verifies file permissions too; if you wish to - know what else it does we suggest you read the source code. -18. Show the output of `ls -lakR .`, asking the user to confirm that the listing -is okay. -19. Create the tarball with the name in the form of -`submit.USERNAME-SLOT.TIMESTAMP`. -20. Run `txzchk(1)` on the tarball. - -If any of the steps fail or if the user says something is not okay, it aborts. -Some of the other checks that are made: - -- If `prog.c` violates [Rule 2](next/rules.html#rule2) (see -[iocccsize.c](https://github.com/ioccc-src/mkiocccentry/blob/master/iocccsize.c)). -- If `prog.c` is empty (see [Rule 1](next/rules.html#rule1) and the -[Guidelines](next/guidelines.html)). -- If `prog.c` has any NUL (`\0`) char (see -[rule_count.c](https://github.com/ioccc-src/mkiocccentry/blob/master/soup/rule_count.c)). -- If `prog.c` has any unknown or invalid trigraph (see -[rule_count.c](https://github.com/ioccc-src/mkiocccentry/blob/master/soup/rule_count.c)). -- If `prog.c` triggers a word buffer overflow (see -[rule_count.c](https://github.com/ioccc-src/mkiocccentry/blob/master/soup/rule_count.c)). -- If `prog.c` triggers an `ungetc(3)` error (see -[rule_count.c](https://github.com/ioccc-src/mkiocccentry/blob/master/soup/rule_count.c)). -- If the first rule in the `Makefile` is not `all`. -- If the `Makefile` does not have a `clean` rule. -- If the `Makefile` does not have a `clobber` rule. -- If the `Makefile` does not have a `try` rule. - -Conditions that one **MUST** correct, and which `mkiocccentry(1)` will prompt until -they are correct, are: - -- Your _contest ID_ is invalidly formed. -- Your _submit slot_ is < 0 or > `MAX_SUBMIT_SLOT` (see -[limit_ioccc.h](https://github.com/ioccc-src/mkiocccentry/blob/master/soup/limit_ioccc.h)). -- Your _title_ is not in the range of 1 through `MAX_TITLE_LEN` chars (see -[limit_ioccc.h](https://github.com/ioccc-src/mkiocccentry/blob/master/soup/limit_ioccc.h)). -- Your _title_ does not match the regexp `^[0-9a-z][0-9a-z._+-]*$`. -- Your _abstract_ is not between 1 and `MAX_ABSTRACT_LEN` chars -(see [limit_ioccc.h](https://github.com/ioccc-src/mkiocccentry/blob/master/soup/limit_ioccc.h)). -- The author count is not 1 through `MAX_AUTHORS` (see -[limit_ioccc.h](https://github.com/ioccc-src/mkiocccentry/blob/master/soup/limit_ioccc.h)). -- An author _name_ is not 1 through `MAX_NAME_LEN` chars (see -[limit_ioccc.h](https://github.com/ioccc-src/mkiocccentry/blob/master/soup/limit_ioccc.h)). -- Duplicate author _name_. -- _Country code_ is invalid (i.e. it is not a ISO 3166-1 2 character code). -- An _email_, if provided, is not in the format of `x@y` or -if `x` or `y` contain a `@`, are empty or if the total length is longer than -`MAX_EMAIL_LEN` (see [limit_ioccc.h](https://github.com/ioccc-src/mkiocccentry/blob/master/soup/limit_ioccc.h)). -- A _URL_ or _alt URL_, if provided, does not start with `http://` -or `https://` or is longer than `MAX_URL_LEN` chars (see -[limit_ioccc.h](https://github.com/ioccc-src/mkiocccentry/blob/master/soup/limit_ioccc.h)) -or does not have anything after the `http://` or `https://`. -- A _mastodon handle_, if provided, is not in the form of -`@user@site` (i.e. starts with an `@`, has text following it and then another -`@` followed by more text and has no other `@`), or if it is longer than `MAX_MASTODON_LEN` (see -[limit_ioccc.h](https://github.com/ioccc-src/mkiocccentry/blob/master/soup/limit_ioccc.h)). -- A _GitHub account_, if provided, does not start with an `@`, -has more than one `@`, does not have any text after the `@` or is longer than `MAX_GITHUB_LEN` (see -[limit_ioccc.h](https://github.com/ioccc-src/mkiocccentry/blob/master/soup/limit_ioccc.h)). -- An _affiliation_, if provided, is longer than -`MAX_AFFILIATION_LEN` (see [limit_ioccc.h](https://github.com/ioccc-src/mkiocccentry/blob/master/soup/limit_ioccc.h)). -- An _author handle_, if the default is not accepted, does -not match the regexp `^[0-9A-Za-z][0-9A-Za-z._+-]*$`. -- An _author handle_ is repeated. - -The program does confirm that the information for each author is correct, -allowing you to correct the information without having to start the program -over. - -Although the `mkiocccentry(1)` tool will verify everything for you, you may wish -to validate different parts individually with the different tools. As the -[rules](next/rules.html) state, each of these tools has a `-h` option. - -See the -FAQ on "[jparse](#jparse)", -the -FAQ on "[.auth.json](#auth_json)", -the -FAQ on "[.info.json](#info_json)", -the -FAQ on "[chkentry](#chkentry)", -the -FAQ on "[txzchk](#txzchk)" -and the -FAQ on "[fnamchk](#fnamchk)" -for more details on the tools that `mkiocccentry` either executes directly or -indirectly as part of the packaging process, especially if you wish to run one -or more of these tools manually. - -See also the -FAQ on "[how to test everything at once without having to answer -questions](#mkiocccentry_test)". - -See also the [Guidelines](next/guidelines.html) and the [Rules](next/rules.html) -(especially [Rule 1](next/rules.html#rule1), [Rule 2](next/rules.html#rule2), [Rule -17](next/rules.html#rule17), [Rule 19](next/rules.html#rule19) and [Rule -20](next/rules.html#rule20)). - -Finally, if you wish to not have to enter the same answers just to update a -submission, see the -FAQ on the "[answers file feature](#answers_file)". - - -Jump to: [top](#) - -
    -### Q 3.1: How can I validate my submission tarball? +### Q 3.0: How can I validate my submission tarball?
    @@ -2210,7 +1792,7 @@ Jump to: [top](#)
    -### Q 3.2: What is the `fnamchk` tool? +### Q 3.1: What is the `fnamchk` tool?
    @@ -2238,15 +1820,15 @@ for more information. Jump to: [top](#) -
    -### Q 3.3: How can I validate my submission directory? +
    +### Q 3.2: How can I validate my submission directory?
    If you want to validate your submission directory manually, including but not -limited to the `.auth.json` and `.info.json` files, you should use `chkentry(1)` +limited to the `.auth.json` and `.info.json` files, you should use `chksubmit(1)` from the [mkiocccentry repo](https://github.com/ioccc-src/mkiocccentry). -The `chkentry(1)` tool runs a variety of checks on your submission directory, +The `chksubmit(1)` tool runs a variety of checks on your submission directory, including, but not limited to, using the [jparse API](https://github.com/ioccc-src/mkiocccentry/blob/master/jparse/man/man3/jparse.3) to validate the two IOCCC specific JSON files (as valid JSON) and additional @@ -2254,7 +1836,7 @@ checks on those files as well. An important thing that it does is verify that your files are the right permissions and that the manifest in the `.info.json` files match what is in the directory. What all the checks are is out of scope of this document; if you wish to know we recommend you read the [source -code](https://github.com/ioccc-src/mkiocccentry/blob/master/chkentry.c). +code](https://github.com/ioccc-src/mkiocccentry/blob/master/chksubmit.c). **NOTE**: the IOCCC [jparse API](https://github.com/ioccc-src/mkiocccentry/blob/master/jparse/man/man3/jparse.3) @@ -2267,7 +1849,7 @@ and FAQ on "[.info.json](#info_json)" for more details on the two required and very important JSON files. -The `chkentry(1)` tool accepts a single arg, a directory that **MUST** have the +The `chksubmit(1)` tool accepts a single arg, a directory that **MUST** have the two JSON files, `.auth.json` and `.info.json` as well as the `prog.c`, `Makefile` and `remarks.md` files along with all the other files listed in the `.info.json` manifest. (Okay there is an option to skip files but this is for @@ -2279,18 +1861,18 @@ As an example, if your submission directory is command: ``` - chkentry 00000000-0000-4000-0000-000000000000-3 + chksubmit 00000000-0000-4000-0000-000000000000-3 ``` If there is a [JSON](https://www.json.org/json-en.html) issue detected by the -`jparse(3)` API (i.e. it is not valid JSON) it is an error and `chkentry(1)` +`jparse(3)` API (i.e. it is not valid JSON) it is an error and `chksubmit(1)` will report this, exiting with a non-zero exit code. If the parsing is OK (i.e. valid JSON) but there is an issue in one or both of the [JSON](https://www.json.org/json-en.html) files in **the context of the IOCCC**, it will report this as an **error**. It also does, as briefly noted above, other checks. -If `chkentry(1)` fails to validate your submission directory your submission +If `chksubmit(1)` fails to validate your submission directory your submission **WILL** be **REJECTED**! This is why you **MUST** make sure you use the `mkiocccentry(1)` tool to form your submission directory. @@ -2300,12 +1882,17 @@ and the FAQ on "[.info.json](#info_json)" as well as [Rule 17](next/rules.html#rule17) for more information. +**NOTE**: the `chksubmit(1)` tool invokes `chkentry(1)` but as a contestant you +do not need to worry about those details. One should use `chksubmit(1)` instead +of `chkentry(1)` when validating a directory; `chkentry(1)` is for the judges +and is what was used in IOCCC28. For IOCCC29 and beyond, `mkiocccentry(1)` uses +`chksubmit(1)` and so should you. Jump to: [top](#)
    -### Q 3.4: What is a `.auth.json` file? +### Q 3.3: What is a `.auth.json` file?
    This file is constructed by the `mkiocccentry(1)` **prior to** forming the xz @@ -2365,11 +1952,11 @@ In order of the file's contents we describe each required field, below: in the [mkiocccentry repo](https://github.com/ioccc-src/mkiocccentry/). If this is not the case your submission **WILL BE** rejected! -- `chkentry_version` (double quoted string) - * The version of `chkentry` that was used to validate the submission +- `chksubmit_version` (double quoted string) + * The version of `chksubmit` that was used to validate the submission directory, including the `.auth.json` file. - **IMPORTANT:** this **MUST** be >= **THIS** IOCCC's `chkentry` version, defined + **IMPORTANT:** this **MUST** be >= **THIS** IOCCC's `chksubmit` version, defined as `CHKENTRY_VERSION` in [soup/version.h](https://github.com/ioccc-src/mkiocccentry/blob/master/soup/version.h) in the [mkiocccentry repo](https://github.com/ioccc-src/mkiocccentry/). If @@ -2526,7 +2113,7 @@ After the `authors` **array** the remaining of a `.auth.json` file holds: `test_formed_timestamp_usec()` in [soup/entry_util.c](https://github.com/ioccc-src/mkiocccentry/blob/master/soup/entry_util.c) in the [mkiocccentry repo](https://github.com/ioccc-src/mkiocccentry/). If - this is not the case `chkentry(1)` will report an **error** and your + this is not the case `chksubmit(1)` will report an **error** and your submission **WILL BE** rejected! - `timestamp_epoch` (double quoted string) @@ -2546,7 +2133,7 @@ After the `authors` **array** the remaining of a `.auth.json` file holds: in the [mkiocccentry repo](https://github.com/ioccc-src/mkiocccentry/). If this is not the case your submission **WILL BE** rejected! -This file will be validated with the `chkentry(1)` tool and if there are any +This file will be validated with the `chksubmit(1)` tool and if there are any problems with it or the submission directory, **it is an error**. If there is an error the tarball will **NOT** be formed by `mkiocccentry`; otherwise the `txzchk(1)` tool will be executed on the tarball. @@ -2554,24 +2141,24 @@ error the tarball will **NOT** be formed by `mkiocccentry`; otherwise the This file will **NOT** be looked at unless the submission wins! Nonetheless, the file **MUST** be present in the submission directory and it **MUST** be valid JSON and it **MUST** pass all IOCCC semantics checks and all other checks -`chkentry(1)` perform. `chkentry(1)` is used by `mkiocccentry(1)` and the judges +`chksubmit(1)` perform. `chksubmit(1)` is used by `mkiocccentry(1)` and the judges will use it on the submission directory as part of the judging process. At the risk of stating the obvious, if your `.auth.json` file is invalid JSON or -is reported invalid by `chkentry(1)`, or if your submission directory is -reported invalid by `chkentry(1)`, your submission will almost certainly be +is reported invalid by `chksubmit(1)`, or if your submission directory is +reported invalid by `chksubmit(1)`, your submission will almost certainly be rejected for violating the [Rules](next/rules.html) and in particular [Rule 17](next/rules.html#rule17). -An obvious example where `chkentry(1)` would fail to validate `.auth.json` is if +An obvious example where `chksubmit(1)` would fail to validate `.auth.json` is if there is a mismatch of type in the JSON file with what is expected, for instance, if in `.auth.json` the `no_comment` that we chose to not comment on is not a string or is the wrong string. Another obvious example is when things are out of range (see above for list). Two more examples would be if a field is missing or if an unknown filed is in the file. In these cases (and any others -that must be established as valid by `chkentry(1)`) your submission would be +that must be established as valid by `chksubmit(1)`) your submission would be rejected for violating [Rule 17](next/rules.html#rule17) and in particular -because `chkentry(1)` would not validate the `.auth.json` file (and maybe other +because `chksubmit(1)` would not validate the `.auth.json` file (and maybe other things too). If you wish to **verify** that your `.auth.json` file is valid **JSON** then see the @@ -2582,7 +2169,7 @@ Jump to: [top](#)
    -### Q 3.5: What is a `.info.json` file? +### Q 3.4: What is a `.info.json` file?
    This file is constructed by the `mkiocccentry(1)` **prior to** forming the xz @@ -2660,11 +2247,11 @@ In order of the file's contents we describe each required field, below: in the [mkiocccentry repo](https://github.com/ioccc-src/mkiocccentry/). If this is not the case your submission **WILL BE** rejected! -- `chkentry_version` (double quoted string) - * The version of `chkentry` that was used to validate the submission +- `chksubmit_version` (double quoted string) + * The version of `chksubmit` that was used to validate the submission directory, including the `.info.json` file. - **IMPORTANT:** this **MUST** be >= **THIS** IOCCC's `chkentry` version, defined + **IMPORTANT:** this **MUST** be >= **THIS** IOCCC's `chksubmit` version, defined as `CHKENTRY_VERSION` in [soup/version.h](https://github.com/ioccc-src/mkiocccentry/blob/master/soup/version.h) in the [mkiocccentry repo](https://github.com/ioccc-src/mkiocccentry/). If @@ -2935,7 +2522,7 @@ The `manifest` **array** also **OPTIONALLY** has one or more of the field: * Any additional file that you need or want to include with your submission. **IMPORTANT:** this MUST **NOT** match a mandatory filename (see above list) - and `chkentry` will verify this for you; it is **ALSO** an **error** if the + and `chksubmit` will verify this for you; it is **ALSO** an **error** if the filenames are not unique, not POSIX plus + safe chars only, if they are the wrong permission and various other things. In these cases you stand a great risk of having your submission rejected for violating [Rule @@ -2965,7 +2552,7 @@ Finally, after the `manifest` **array**, the following fields **MUST** exist: `test_formed_timestamp_usec()` in [soup/entry_util.c](https://github.com/ioccc-src/mkiocccentry/blob/master/soup/entry_util.c) in the [mkiocccentry repo](https://github.com/ioccc-src/mkiocccentry/). If - this is not the case `chkentry(1)` will report an **error** and your + this is not the case `chksubmit(1)` will report an **error** and your submission **WILL BE** rejected! - `timestamp_epoch` (double quoted string) @@ -2985,24 +2572,24 @@ Finally, after the `manifest` **array**, the following fields **MUST** exist: in the [mkiocccentry repo](https://github.com/ioccc-src/mkiocccentry/). If this is not the case your submission **WILL BE** rejected! -This file will be validated with the `chkentry(1)` tool and if there are any +This file will be validated with the `chksubmit(1)` tool and if there are any problems with it or the submission directory, **it is an error**. If there is an error the tarball will **NOT** be formed by `mkiocccentry`; otherwise the `txzchk(1)` tool will be executed on the tarball. -When the [Judges](judges.html) use `chkentry(1)` on your submission directory, +When the [Judges](judges.html) use `chksubmit(1)` on your submission directory, if this JSON file is invalid JSON or does not match the requirements outlined above, or if any other is found, your submission **WILL BE** rejected. -An obvious example where `chkentry` would fail to validate `.info.json` is if +An obvious example where `chksubmit` would fail to validate `.info.json` is if there is a mismatch of type in the JSON file with what is expected, for instance, if in `.info.json` the `no_comment` that we chose to not comment on is not a string or is the wrong string. Another obvious example is when things are out of range (see above for list). Two more examples would be if a field is missing or if an unknown filed is in the file. In these cases (and any others -that must be established as valid by `chkentry`) your submission would be +that must be established as valid by `chksubmit`) your submission would be rejected for violating [Rule 17](next/rules.html#rule17) and in particular -because `chkentry` would not validate the `.info.json` file. +because `chksubmit` would not validate the `.info.json` file. If you wish to **verify** that your `.info.json` file is valid **JSON** then see the FAQ on "[validating JSON documents](#validating_json)". @@ -3013,7 +2600,7 @@ Jump to: [top](#)
    -### Q 3.6: What is an `author_handle`? +### Q 3.5: What is an `author_handle`?
    An `author_handle` is string that refers to a given author and is unique to the @@ -3083,7 +2670,7 @@ Jump to: [top](#)
    -### Q 3.7: What is an `author_handle.json` file and how are they used? +### Q 3.6: What is an `author_handle.json` file and how are they used?
    @@ -3641,7 +3228,7 @@ Jump to: [top](#)
    -### Q 3.8: How can I find my author handle? +### Q 3.7: How can I find my author handle?
    If you are an _author_ of a winning _entry_, you may find your own _author_handle_ @@ -3688,7 +3275,7 @@ Jump to: [top](#)
    -### Q 3.9: What is an `entry_id`? +### Q 3.8: What is an `entry_id`?
    An `entry_id` is a string that identifies a winning entry of the IOCCC. @@ -3706,7 +3293,7 @@ Jump to: [top](#)
    -### Q 3.10: What is a `.entry.json` file and how is it used? +### Q 3.9: What is a `.entry.json` file and how is it used?
    **TL:DR**: The contents of this JSON file contain information about each winning @@ -4223,7 +3810,7 @@ Jump to: [top](#)
    -### Q 3.11: How can I validate any JSON document? +### Q 3.10: How can I validate any JSON document?
    @@ -4271,7 +3858,7 @@ the tool. repo](https://github.com/xexyl/jparse/issues) but we recommend you compile and install via the `mkiocccentry` repo because it has the dependencies built in, and because the `mkiocccentry` copy is that which is used by the current IOCCC, -as the two can be different at times. +as the two can sometimes be different. Jump to: [top](#) diff --git a/next/guidelines.html b/next/guidelines.html index b5be100a6..742ad275e 100644 --- a/next/guidelines.html +++ b/next/guidelines.html @@ -488,12 +488,10 @@ writing by contacting the judges.

    -These IOCCC guidelines are version 28.48 2025-09-28. -

    -

    -The markdown form of these guidelines is available for download. +These IOCCC guidelines are version 28.49 2025-11-17.

    +

    The markdown form of these guidelines is available for download.

    IMPORTANT: Be SURE to read the IOCCC rules.

    Jump to: top

    @@ -519,11 +517,9 @@ about them. The IOCCC guidelines should be viewed guidelines but remain within the rules are allowed. Even so, you are safer if you remain within the IOCCC guidelines.

    -

    -Of course if a guideline is talking about a rule and you break that guideline, +

    Of course if a guideline is talking about a rule and you break that guideline, you stand a good chance of having your submission rejected for breaking the -rule, not the guideline. -

    +rule, not the guideline.

    You SHOULD read the CURRENT IOCCC rules, prior to submitting code to the contest.

    Jump to: top

    @@ -547,128 +543,97 @@ When this happens, you may begin uploading your submissions to the IOCCC. This contest will enter the judging state on 2025-06-05 04:03:02.010099 UTC. When this happens, you may no longer upload your submissions to the IOCCC.

    -

    -IMPORTANT NOTE: Until the contest enters the open state, any or all -of the above dates and times may change AT ANY TIME! -

    +

    IMPORTANT NOTE: Until the contest enters the open state, any or all +of the above dates and times may change AT ANY TIME!

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

    -

    -Until the contest status becomes open, +

    Until the contest status becomes open, the IOCCC rules, IOCCC guidelines and the tools in the mkiocccentry repo SHOULD be considered provisional BETA versions and may be adjusted AT ANY TIME -before the contest status becomes open. -

    -

    -See the +before the contest status becomes open.

    +

    See the FAQ on “how to register and submit to the IOCCC” for instructions on registering and participating in the IOCCC, as the process -may change from contest to contest. -

    -

    -To assist in the formation of the xz compressed tarball for submission, use the -mkiocccentry(1) tool as found in the mkiocccentry repo. -

    -

    -See FAQs regarding: -

    +may change from contest to contest.

    +

    To assist in the formation of the xz compressed tarball for submission, use the +mkiocccentry(1) tool as found in the mkiocccentry repo.

    +

    See FAQs regarding:

    -

    -Uploading a tarball not formed by mkiocccentry(1) puts you at a very big risk of +

    Uploading a tarball not formed by mkiocccentry(1) puts you at a very big risk of violating Rule 17, especially as mkiocccentry(1) does a great number of things that are required, and it also runs many checks, and if any of those checks fail, you are at a very great risk of having your submission -rejected for violating Rule 17. -

    -

    -We STRONGLY recommend you do install the -mkiocccentry toolkit. -

    -

    -IMPORTANT NOTE: the tools that require other tools, mkiocccentry(1) and +rejected for violating Rule 17.

    +

    We STRONGLY recommend you do install the +mkiocccentry toolkit.

    +

    IMPORTANT NOTE: the tools that require other tools, mkiocccentry(1) and txzchk(1), will, as of version 2.0.2 2025-03-11, search under $PATH. If you have an earlier version and you have not installed the tools and run the tools from outside the repo directory, you will have to use the options to the -tools to set the path to the required tools. -

    -

    -See the +tools to set the path to the required tools.

    +

    See the FAQ on “obtaining and compiling the most recent mkiocccentry tools” and the FAQ on “how to enter the IOCCC” as that FAQ has important details on how to register as well as -how to upload your submission to the IOCCC. -

    -

    -See also the -FAQ on “what the minimum required versions are for this -contest” -for more details on how to verify you have the correct versions for this -contest. -

    -

    -While the contest is open, you may modify your +how to upload your submission to the IOCCC.

    +

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

    -

    -HINT: so that you do not have to repeatedly answer all the +submit server.

    +

    HINT: so that you do not have to repeatedly answer all the questions, the mkiocccentry(1) tool has the options -a answers, -A answers and -i answers, where -a will write to an answers file (if it does not already exist), -A WILL OVERWRITE THE FILE and -i will read the answers from -the file. If you use -A, BE SURE you don’t overwrite another file by accident! -

    -

    -Be aware that even with the -i answers you will still be required to confirm +the file. If you use -A, BE SURE you don’t overwrite another file by accident!

    +

    Be aware that even with the -i answers you will still be required to confirm most if not all y/n questions - you just don’t have to input the name of the submission, the abstract, the author details etc. If you really wish to circumvent this you can use the -Y option but we do not recommend this because -if your update breaks a rule or there is some problem, you might not see it. -

    -

    -To help with not having to repeatedly enter a UUID, whether for the same +if your update breaks a rule or there is some problem, you might not see it.

    +

    To help with not having to repeatedly enter a UUID, whether for the same submission or multiple submissions, you can use the -u uuidfile or -U UUID option. See the FAQ on “how to avoid re-entering your UUID” for more details. Note that the -i answers option cannot be used with the UUID -options as the answers file includes the UUID. -

    -

    -The overall size limit (see Rule 2a) on prog.c has been +options as the answers file includes the UUID.

    +

    The overall size limit (see Rule 2a) on prog.c has been increased from 4096 to 4993 bytes. The Rule 2a size was changed from 4096 to 4993 to keep the “2b to 2a” size ratio to a value similar to the 2001-2012 and -2013-2020 IOCCC eras. +2013-2020 IOCCC eras.

    +

    The Rule 2b size has increased from 2053 to 2503 +bytes.

    +

    +However, you should pay especial attention to our remarks in the IOCCC28 +index.html:

    -The Rule 2b size has increased from 2053 to 2503 -bytes. -

    -

    -Your submission must satisfy BOTH the maximum size -Rule 2a AND the IOCCC size Rule 2b. -

    -

    -To check your code against Rule 2, use the iocccentry(1) tool. -For example: +

    +

    IMPORTANT HINT: Only 3 of the 23 IOCCC28 winners came close to the +Rule 2 size limit. Large code size isn’t +everything. :-) Those submitting to future contents should take a careful +note of that fact.

    +

    +

    Your submission must satisfy BOTH the maximum size +Rule 2a AND the IOCCC size Rule 2b.

    +

    To check your code against Rule 2, use the iocccentry(1) tool. +For example:

        iocccsize prog.c
    -

    -The IOCCC size tool algorithm can be summarized as follows: -

    +

    The IOCCC size tool 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 @@ -678,34 +643,26 @@ 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. This is a feature, not a bug! -

    -

    -In cases where the above summary and the algorithm implemented by +

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

    +

    In cases where the above summary and the algorithm implemented by the IOCCC size tool iocccsize(1) conflict, the algorithm implemented -by the current version of iocccsize(1) is preferred by the IOCCC judges. -

    -

    -In other words, make sure iocccsize does not flag any issues with your -prog.c. -

    -

    -There are at least 2 other reasons for selecting 2503 as the 2nd limit besides +by the current version of iocccsize(1) is preferred by the IOCCC judges.

    +

    In other words, make sure iocccsize does not flag any issues with your +prog.c.

    +

    There are at least 2 other reasons for selecting 2503 as the 2nd limit besides the fact that 2503 is a prime. These reasons may be searched for and discovered if you are “Curios!” about 2503. :-) Moreover, 2053 was the number of the kernel disk pack of one of the judge’s -BESM-6, and 2503 is a decimal anagram of 2053. -

    +BESM-6, and 2503 is a decimal anagram of 2053.

    Take note that this secondary limit imposed by the IOCCC size tool obviates some of the need to #define C reserved words in an effort to get around the size limits of Rule 2.

    Yes Virginia, that is a hint!

    +

    The official locale of the IOCCC is C.

    -The official locale of the IOCCC is C. +Did you really think anything else? :-)

    -

    The mkiocccentry toolkit, as of Release version 2.4.4 2025-03-15, will run with a locale set to C. @@ -747,8 +704,7 @@ requirements document or a customer request is important. For this reason, we often award ‘Best abuse of the rules’ or ‘Worst abuse of the rules’ or some variation to a submission that illustrates this point in an ironic way.

    -

    -The IOCCC has a rich history of remarkable winning entries created by +

    The IOCCC has a rich history of remarkable winning entries created by authors who skillfully employed various techniques to develop their code. While it is NOT required, you are allowed to use tools to develop and test your submission. These tools may include, but are not limited @@ -756,67 +712,48 @@ to code generators, code analysis tools, static code analysis tools, runtime analysis tools, machine learning tools, natural language models, code copilot tools, so-called AI services, large language models (LLMS), etc. If you do make use of such tools or services, then we ENCOURAGE you to describe -how you used such tools in your remarks.md file. -

    -

    -You may use git, or services such as GitHub +how you used such tools in your remarks.md file.

    +

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

    -

    -Submissions will be judged in an environment that has no IDE. +submissions that require them 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, and other tools found in +an IDE will be rejected.

    +

    We will use the make(1) tool, your Makefile, and other tools found in Single UNIX Specification environments and systems that conform to the Single UNIX Specification -in the building and compiling of your submission. -

    +in the building and compiling of your submission.

    We do realize that there are holes in the rules, and invite submitters to attempt to exploit them. We may award ‘Worst abuse of the rules’ or ‘Best abuse of the rules’ or some variation and then plug the hole next year.

    -

    -When we do need to plug a hole in the IOCCC rules or IOCCC +

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

    -

    -There may be fewer than 2^7+1 reasons why these IOCCC -guidelines seem obfuscated. -

    -

    -IMPORTANT: Be sure that your submission works as documented in your +smaller. Or, maybe not. :-)

    +

    There may be fewer than 2^7+1 reasons why these IOCCC +guidelines seem obfuscated.

    +

    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 BETTER off -documenting such bugs and/or mis-features in your remarks.md file. -

    -

    -Consider an example of a prime number +fall down because they didn’t work as documented.

    +

    If you submission has bugs and/or mis-features, you are MUCH BETTER off +documenting such bugs and/or mis-features in your remarks.md file.

    +

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

    +Noting such a bug in your remarks.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 +

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

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

    @@ -828,26 +765,17 @@ misleading comments and variable names might be a VERY GOOD START

    Jump to: top

    mkiocccentry

    -

    -Rule 17 (the mkiocccentry(1) rule) states that -you REALLY SHOULD use the mkiocccentry(1) tool to package your submission tarball. -

    -

    -See the mkiocccentry repo -for the mkiocccentry(1) tool and below for more details. -

    -

    -IMPORTANT NOTE: make CERTAIN you have the most recent version of the +

    Rule 17 (the mkiocccentry(1) rule) states that +you REALLY SHOULD use the mkiocccentry(1) tool to package your submission tarball.

    +

    See the mkiocccentry repo +for the mkiocccentry(1) tool and below for more details.

    +

    IMPORTANT NOTE: make CERTAIN you have the most recent version of the mkiocccentry toolkit! See the -FAQ on “obtaining the mkiocccentry toolkit”. -

    -

    -mkiocccentry runs a number of checks, by the tool itself and by executing +FAQ on “obtaining the mkiocccentry toolkit”.

    +

    mkiocccentry runs a number of checks, by the tool itself and by executing other tools, before packaging your xz compressed tarball, including running -chksubmit(1) on the submission directory. -

    -

    -If mkiocccentry encounters an error, the program will exit and the xz +chksubmit(1) on the submission directory.

    +

    If mkiocccentry encounters an error, the program will exit and the xz compressed tarball will not be formed. For instance, if chksubmit fails to validate the submission directory, either because of a validation error in the .auth.json or .info.json @@ -857,151 +785,111 @@ something else that mkiocccentry(1) creates or does, it is an mkiocccentry bug report page. PLEASE run the bug_report.sh script to help us out here! See the -FAQ on “reporting mkiocccentry bugs”. -

    -

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

    -

    -However, even if mkiocccentry or one of the tools it invokes reports an error, +FAQ on “reporting mkiocccentry bugs”.

    +

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

    +

    However, even if mkiocccentry or one of the tools it invokes reports an error, it does not necessarily mean it is a bug in the code. It might be an issue with your submission. Thus if you report an error as a bug it might not be something -that will be fixed as there might not be anything wrong with the tools. -

    -

    -On the other hand, some conditions flagged by mkiocccentry(1) are warnings +that will be fixed as there might not be anything wrong with the tools.

    +

    On the other hand, some conditions flagged by mkiocccentry(1) are warnings and it allows you to override these, if you wish. If you’re brave enough you can use the -W option to ignore all warnings but this is a big risk; the -y option will assume ‘yes’ to most questions but this is also a big risk. Using -Y will say ‘yes’ to even more prompts. Needless to say, we do NOT -recommend these options. -

    -

    -In many places it will prompt you to verify what you input, allowing you to +recommend these options.

    +

    In many places it will prompt you to verify what you input, allowing you to correct details as you go along. Be advised that there is a default answer and if you press enter it will proceed with that default, so make sure you have -provided the correct answer. -

    -

    -If you wish to test that your submission passes the mkiocccentry(1) tests +provided the correct answer.

    +

    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 option to mkiocccentry for the tool to pseudo-randomly create answers for you. -For example: -

    +For example:

        mkiocccentry -d workdir topdir
    -

    -IMPORTANT NOTE: if you run an IOCCC related tool outside the repo directory +

    IMPORTANT NOTE: if you run an IOCCC related tool outside the repo directory (specifying the absolute or relative path to the tool) and you have not installed the tools (and we STRONGLY recommend you do install them), then you will have to specify the options (such as paths) for the tools that are required like -chksubmit(1), txzchk(1) and fnamchk(1). -

    -

    -Make sure you have +chksubmit(1), txzchk(1) and fnamchk(1).

    +

    Make sure you have the latest version of of the mkiocccentry toolkit -so that you do not violate Rule 17 by mistake. -

    +so that you do not violate Rule 17 by mistake.

    Jump to: top

    mkiocccentry(1) synopsis

    -

    -The synopsis of the mkiocccentry(1) tool is: -

    +

    The synopsis of the mkiocccentry(1) tool is:

        mkiocccentry [options] workdir topdir
    -

    -To help you with editing a submission, the mkiocccentry(1) tool has +

    To help you with editing a submission, the mkiocccentry(1) tool has some options to write OR read from an answers file so you do not have to input the information about the author(s) and the submission more than once, unless of course you need to make some changes, in which case you can use the option that overwrites the file. If you do use the overwrite option, MAKE SURE you do -not overwrite another file! -

    -

    -See the +not overwrite another file!

    +

    See the FAQ on the “mkiocccentry tool” for how to use this tool and the FAQ on the “finer details of mkiocccentry” -for even more information. -

    +for even more information.

    Other mkiocccentry tools

    -

    -The mkiocccentry(1) tool will execute a number of tools, some of which will -execute one or more additional tools. -

    +

    The mkiocccentry(1) tool will execute a number of tools, some of which will +execute one or more additional tools.

    iocccsize

    -

    -mkiocccentry(1) will use code from iocccsize(1) which detects a number of +

    mkiocccentry(1) will use code from iocccsize(1) which detects a number of issues (such as Rule 2) that you may ignore, if you wish, as -noted above. -

    -

    -In other words, you no longer need to run iocccsize manually. However, the -checks described above are still made but through the mkiocccentry(1) tool itself. -

    +noted above.

    +

    In other words, you no longer need to run iocccsize manually. However, the +checks described above are still made but through the mkiocccentry(1) tool itself.

    Jump to: top

    -

    chkentry

    -

    -mkiocccentry(1) will write two JSON files: .auth.json and +

    chksubmit

    +

    mkiocccentry(1) will write two JSON files: .auth.json and .info.json. These files contain information about the author(s) and about the -submission. After these files are formed, the chkentry(1) tool will be run on +submission. After these files are formed, the chksubmit(1) tool will be run on the submission directory; this tool not only validates the two JSON files (and runs specific checks on them after validating the JSON), but it also verifies that what is in the manifest in .info.json matches the contents of -the directory, in addition to other checks. If chkentry(1) fails to validate -anything at all, your submission WILL BE rejected! -

    -

    -IMPORTANT: although chkentry(1) validates the files in the directory, it +the directory, in addition to other checks. If chksubmit(1) fails to validate +anything at all, your submission WILL BE rejected!

    +

    IMPORTANT: although chksubmit(1) validates the files in the directory, it only inspects the contents of the two JSON files; it performs other kinds of checks on the other files, and those checks are run on the two JSON files as -well. -

    -

    -If you submit your own JSON files (other than .auth.json and +well.

    +

    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 such invalid JSON files, PLEASE -document and explain this in your remarks.md file. -

    +document and explain this in your remarks.md file.

    -If chkentry does not pass and you used mkiocccentry(1) it is very likely a +On the other hand, some people might question what actually constitutes a valid +JSON file. :-) +

    +

    If chksubmit does not pass and you used mkiocccentry(1) it is very likely a bug and you should report it as a bug at the mkiocccentry issues page. -PLEASE run the command: -

    +PLEASE run the command:

        make bug_report
    -

    -from the top level repo directory itself and attach the bug report file (it will +

    from the top level repo directory itself and attach the bug report file (it will tell you the name of the file). See also the -FAQ on “reporting mkiocccentry bugs”. -

    -

    -Assuming that chkentry(1) successfully validates your submission directory, +FAQ on “reporting mkiocccentry bugs”.

    +

    Assuming that chksubmit(1) successfully validates your submission directory, the tarball will be formed and then txzchk(1) will be executed on it. In this case, there should be no problems, as mkiocccentry(1) should NOT form a -tarball if there are any issues. -

    -

    -If mkiocccentry(1) is used and chkentry(1) fails to validate your submission +tarball if there are any issues.

    +

    If mkiocccentry(1) is used and chksubmit(1) fails to validate your submission directory, then unless it is a system specific problem, it could be a bug in -mkiocccentry(1), chkentry(1) or possibly jparse, although this is unlikely. -Nonetheless, if you believe there is a bug, you may report it as explained above. -

    -

    -If you want to know what .auth.json is, see the +mkiocccentry(1), chksubmit(1) or possibly jparse, although this is unlikely. +Nonetheless, if you believe there is a bug, you may report it as explained above.

    +

    If you want to know what .auth.json is, see the FAQ on “.auth.json”. If you want to know what the .info.json file is, see the FAQ on “.info.json”. -On the other hand, if you want to know a bit more details about chkentry(1), see the -FAQ about “chkentry”. -

    -

    -chkentry uses the jparse library. See the +On the other hand, if you want to know a bit more details about chksubmit(1), see the +FAQ about “chksubmit”.

    +

    chksubmit uses the jparse library. See the jparse README.md in the mkiocccentry GitHub repo subdirectory @@ -1010,56 +898,45 @@ the mkiocccentry GitHub repo subdirectory jparse, for more -details. -

    -

    -The jparse parser, library and tools were co-developed by Cody Boone +details.

    +

    The jparse parser, library and tools were co-developed by Cody Boone Ferguson and Landon Curt Noll in 2022-2025 and come from the jparse repo. However, the mkiocccentry tools use a clone of the jparse repo at a specific release. Thus the mkiocccentry will at times be behind the -jparse repo! -

    -

    -You do NOT need to install jparse from the jparse +jparse repo!

    +

    You do NOT need to install jparse from the jparse repo! The mkiocccentry tools link in the -static library from mkiocccentry’s clone. -

    -

    -The mkiocccentry toolkit also has a clone of both the dbg +static library from mkiocccentry’s clone.

    +

    The mkiocccentry toolkit also has a clone of both the dbg library and the dyn_array library; the dyn_array library uses the dbg library and the jparse library uses both libraries but unlike in the jparse repo, the libraries do not need to be -installed separately, in order to use the tools in mkiocccentry. -

    -

    -In other words, mkiocccentry contains everything you need, and even if you +installed separately, in order to use the tools in mkiocccentry.

    +

    In other words, mkiocccentry contains everything you need, and even if you do install the libraries from their respective repos, it/they will not be used when compiling the mkiocccentry tools. This is important to make sure that you’re using the correct versions, which is also verified by -chkentry (in the JSON files created by mkiocccentry(1)). See Rule -17! -

    +chksubmit (in the JSON files created by mkiocccentry(1)). See Rule +17!

    -Please see the -FAQ on “validating your submission directory -for more details on chkentry(1). +We HIGHLY recommend you install the mkiocccentry toolkit, however.

    -

    -You might also wish to see the +

    Please see the +FAQ on “validating your submission directory +for more details on chksubmit(1).

    +

    You might also wish to see the FAQ on “.auth.json” and the FAQ on “.info.json” -for much more information on these files. -

    +for much more information on these files.

    Jump to: top

    txzchk

    -

    -txzchk(1) performs a wide number of sanity checks on the xz compressed +

    txzchk(1) performs a wide number of sanity checks on the xz compressed tarball; if any issues are found (‘feathers are stuck in the tarball’ :-) ) AND if and ONLY IF you used mkiocccentry(1), then it is possibly a bug in one of the tools and you might want to report it as a bug at the @@ -1067,108 +944,86 @@ mkiocccentry bug report page. PLEASE run the bug_report.sh script to help us out here! You may do this by running from the top level directory of the repo make bug_report. See the -FAQ on “reporting mkiocccentry bugs”. -

    -

    -As part of its algorithm, txzchk(1) will run fnamchk(1) on the +FAQ on “reporting mkiocccentry bugs”.

    +

    As part of its algorithm, txzchk(1) will run fnamchk(1) on the tarball to verify that the filename is valid. See the FAQ on “fnamchk” -and the fnamchk section below for more details on this tool. -

    -

    -It is beyond the scope of this document to discuss the many tests that +and the fnamchk section below for more details on this tool.

    +

    It is beyond the scope of this document to discuss the many tests that txzchk(1) performs; if you wish to know, we refer you to the source code or the man -page. You might just find a fun option if you do either of these! -

    -

    -Of course, as txzchk does not extract the tarball, it is possible that if you +page. You might just find a fun option if you do either of these!

    +

    Of course, as txzchk does not extract the tarball, it is possible that if you manually package your submission tarball and/or find and exploit a missing -check, you could still be violating Rule 17. -

    +check, you could still be violating Rule 17.

    Including optional and extra files

    -The maximum total number of files that may be submitted has changed to 39 files. -However, of those files, 5 are mandatory (prog.c, Makefile, remarks.md and -the two JSON files generated by mkiocccentry(1), .info.json and -.auth.json). +The maximum total number of extra files that may be submitted is 31.

    -Additionally, three of the files, if included, MUST be -specific file(name)s AND in the top level directory, or they will be counted as -an extra file, not an optional 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.

    -In particular, any file that is not prog.c, Makefile, remarks.md, -try.sh, prog.alt.c or try.alt.sh will be counted as an extra file, and if -try.sh, prog.alt.c or try.alt.sh are not in the top level submission -directory they will also be counted as an extra file. The .info.json and -.auth.json files are not counted as extra files but are required. +Of course any dot file that is not .auth.json and .info.json will result in +a violation of Rule 17, regardless of its depth.

    -

    -In other words, the actual amount of EXTRA files is 31. -

    -

    -If you use an optional filename for something other than their intended use +

    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. For more details on the optional files, see the +abuse of rules.

    +

    +For information on the try script files see the FAQ on the “try.sh script system” -and the +and for more details on alt code (including the try.alt.sh script) see the FAQ on “alt code”.

    -If you REALLY MUST include more files than the limit allows, then you may do so by including as an extra -file, a tarball. This does NOT have to pass txzchk(1) tests; only the -submission tarball must pass the txzchk(1) tests. +If you really MUST include more files than the limit allows, then you may do +so by including as an extra file, a tarball. This does NOT have to pass +txzchk(1) tests; only the submission tarball must pass the txzchk(1) tests.

    -If you DO include a tarball, and the build process or the program extracts -said tarball(s), the make clobber rule MUST remove the extracted files. Even so, if you -include a tarball to get past the limit on the number of files, you MUST -justify this in your remarks.md file. +You MUST justify including extra files beyond the limit, should you do so. +Even so this does not mean it will be considered valid.

    -IMPORTANT REMINDER: make SURE your tarball does NOT reveal who you are! +If you use a tarball for a depth beyond the maximum, you MUST justify this +as well. Even so this does not mean it will be considered valid. +

    +

    If you DO include a tarball, and the build process or the program extracts +said tarball(s), the make clobber rule MUST remove the extracted files.

    +

    IMPORTANT REMINDER: make SURE your tarball does NOT reveal who you are! The mkiocccentry(1) tool creates a v7 format tarball to prevent this. You can -do the same like: -

    +do the same like:

        tar --format=v7 -cJf foo.txz directory
    -

    -See Rule 17 and in particular the part about the maximum -number of files. If you do not follow these points, you -are at a great risk of violating Rule 17! -

    -

    -NOTE: if you want to include a test-suite that requires a lot of files, +

    See Rule 17 and also the +FAQ on “maximum number of files”.

    +

    If you do not follow these points, you +are at a great risk of violating Rule 17!

    +

    NOTE: if you want to include a test-suite that requires a lot of files, please suggest this in your remarks.md and if your submission wins it can -be done. In other words you should not use a tarball for a test-suite unless you +be done. In other words you should NOT use a tarball for a test-suite unless you have a very good reason for this (and if you do, make SURE you specify why -in your remarks.md file). -

    -

    -See also the -FAQ on “txzchk”. -

    +in your remarks.md file).

    +

    See also the +FAQ on “txzchk”.

    Jump to: top

    fnamchk(1)

    -

    -As an important part of its algorithm, txzchk(1) directly executes +

    As an important part of its algorithm, txzchk(1) directly executes fnamchk(1). If the filename is invalid (or the filename does not match the directory name of the tarball) then it is an error and you risk violating Rule 17. Nevertheless, you can run the tool manually, -should you wish to. -

    -

    -For more information on fnamchk and how to manually validate your submission +should you wish to.

    +

    For more information on fnamchk and how to manually validate your submission tarball filename, see the -FAQ on “fnamchk”. -

    -

    -It is extremely unlikely that fnamchk(1) reporting an invalid filename is a +FAQ on “fnamchk”.

    +

    It is extremely unlikely that fnamchk(1) reporting an invalid filename is a bug in fnamchk(1) and as such, ignoring such an issue risks violating Rule 17 which is a big risk. Of course, using mkiocccentry(1) would prevent this from happening as it would not create such a file anyway. If @@ -1176,111 +1031,86 @@ would prevent this from happening as it would not create such a file anyway. If you should report it as a bug at the mkiocccentry issues page. See the -FAQ on “reporting mkiocccentry bugs”. -

    -

    -As you can see, the use of mkiocccentry(1) is HIGHLY RECOMMENDED, and at +FAQ on “reporting mkiocccentry bugs”.

    +

    As you can see, the use of mkiocccentry(1) is HIGHLY RECOMMENDED, and at the risk of stating the obvious, you run A VERY BIG RISK of having your submission rejected if you package your own tarball, and there are ANY -problems. For instance, if chkentry(1) found a problem in your .info.json +problems. For instance, if chksubmit(1) found a problem in your .info.json file, the mkiocccentry(1) tool would not package it. But if you were to package it manually, you would be violating Rule 17. But even if -everything checks out OK you should NOT assume that everything IS OK. -

    +everything checks out OK you should NOT assume that everything IS OK.

    -

    Problems and/or bugs in tools

    +

    Problems and/or bugs in the mkiocccentry toolkit

    -

    -Although the tools have been tested extensively, it is nonetheless possible for bugs to +

    Although the tools have been tested extensively, it is nonetheless possible for bugs to exist in the code, as all programmers know. In this case, please ask for help or report what you think is a bug via the bug report issues page in the mkiocccentry -repo. -

    -

    -Of course, it is also possible for mkiocccentry(1), or one or more of the +repo.

    +

    Of course, it is also possible for mkiocccentry(1), or one or more of the tools it executes (or another tool executes), to fail, but NOT because of a bug. An example problem is if there is not enough memory available or if some other library or syscall fails. Nonetheless it might be worth reporting as a bug; it is a judgement call: if it’s a bug it’ll be addressed and if it’s not -that’s OK too! -

    +that’s OK too!

    Makefiles

    -

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

    +

    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 +

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

    +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. +This helps us fit the Makefile into a winning entry, should your submission win.

    -

    -We suggest that you compile your submission with a commonly available +

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

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

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

    +your remarks.md file, AND adjust your Makefile accordingly.

    -One reason that you might have to change the flags, is that the optimiser is +You really should NOT redefine CC because doing so makes it less portable. <– Hint! +

    +

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

    +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! -

    +

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

    +

    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
    @@ -1293,277 +1123,209 @@ by modifying the CSTD Makefile variable. For example, to use
    -

    -You may change the level of optimization and compiler debug 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: -

    +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: -

    +

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

    +

    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, +

    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 +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 +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: -

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

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

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

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

    +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: -

    +

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

    +

    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 +

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

    +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: -

    +

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

    +

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

    +

    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 +

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

    -

    -While people are free to manage their submission under git(1) or even use a +is in your submission tarball itself.

    +

    While people are free to manage their submission under git(1) or even use a GitHub repo, dot-files and dot-directories such as .git are not allowed in a -submission. -

    -

    -The mkiocccentry(1) tool will ignore dot-files and dot-directories (such as +submission.

    +

    The mkiocccentry(1) tool will ignore dot-files and dot-directories (such as .vimrc, .bashrc, .git and .github) and not put them in the submission’s compressed tarball. So while you may use such files and directories to help develop your submission, they won’t be included when you run -the mkiocccentry(1) tool. -

    -

    -Even if you did manage to get dot files or dot directories in the tarball +the mkiocccentry(1) tool.

    +

    Even if you did manage to get dot files or dot directories in the tarball somehow, txzchk(1) will flag it as an error. When the judges run txzchk(1) on the uploaded submission compressed tarball, if anything is wrong, for instance if you “sneak in” any dot files or dot directories, the submission -WILL BE REJECTED for violating Rule 17! -

    -

    -You may use whatever tools you need to develop your submission, including the +WILL BE REJECTED for violating Rule 17!

    +

    You may use whatever tools you need to develop your submission, including the use of git(1) or gh(1), just be sure that your submission code and your -submission Makefile don’t depend on such tools. +submission Makefile don’t depend on such tools.

    +

    Of course if you do use GitHub to work on your submission, you might want to +make the repo private so you don’t reveal who you are. :-)

    +

    +In other words, make SURE you keep anonymous who submitted the code!

    -Of course if you do use GitHub to work on your submission, you might want to -make the repo private so you don’t reveal who you are. :-) -

    -

    -If this is not clear, please do NOT use these tools to help with the +Please do NOT use these tools to help with the clobber rule! For instance, do NOT use git clean! Not only does this depend on the user having git(1) but it also does not account for the submission tarballs. Even worse is when someone does have it in a git(1) repo it will remove files that are not under git(1) control! Instead, see the clobber rule in the example Makefile to see how to manage this.

    -

    -In other words, for make clobber, do something like: -

    +

    In other words, for make clobber, do something like:

        clobber:
             ${RM} -f foo bar baz

    and NOT something like this:

        # do NOT do this!
     clobber:
             -git clean -f   # WRONG !!!
    -

    -And do NOT use git for any other Makefile rule either. -

    -

    -NOTE: mkiocccentry(1) will directly run make clobber in the submission +

    And do NOT use git for any other Makefile rule either.

    +

    NOTE: mkiocccentry(1) will directly run make clobber in the submission directory. And although it is not an error if this fails, if it fails because the Makefile does not have a clobber rule, it will be flagged by mkiocccentry(1) -(you may ignore this but it does put you at a risk of violating the rules). -

    +(you may ignore this but it does put you at a risk of violating the rules).

    Jump to: top

    OUR LIKES AND DISLIKES:

    -

    -We VERY MUCH LIKE submissions that use an edited variant of the +

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

    -

    -It is VERY MUCH appreciated if your remarks have some educational +the idea of “spoilers”. You should not encrypt or rot13 content in your remarks.md file.

    +

    It is VERY MUCH appreciated if your remarks 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 +EXCELLENT bonus.

    +

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

    +the same applies with the try.alt.sh script):

    -

    -Of course, it is quite possible that only one invocation is +

    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”. +FAQ on “submitting try.sh and try.alt.sh scripts”.

    +

    +Even if it only has one invocation we still LIKE the try scripts.

    -You might wish to add ./try.sh to the try rule in the Makefile you submit. -If you have alternate code, then you can use the try.alt rule as well. +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.alt rule in +the Makefile. +

    +

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

    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 @@ -1572,27 +1334,19 @@ 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. -

    +

    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;
     this_is_not;       /* <-- Try to avoid implicit type declarations */
    -

    -We tend to like less a submission that requires either +

    We tend to like less a submission that requires either gcc OR clang. We prefer submissions that can compile -under BOTH gcc AND clang. -

    -

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

    -

    -We DISLIKE the use of obscure compiler flags, especially +under BOTH gcc AND clang. Hint!

    +

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

    +

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

    +that you not use any really obscure compiler flags if you can help it.

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

         int main() {
@@ -1605,9 +1359,7 @@ of nested functions such as:
    
 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.
-
    
+
    We DISLIKE submissions that require the use of -fnested-functions.
    
 
    We prefer programs that do not require a fish license: crayons and
 cat detector vans not withstanding.
    
 
    If your submission uses functions that have a variable number of
@@ -1623,17 +1375,15 @@ not portable and must not be used:
    
 
  • using va_list as a structure or union
    • 
 
 
    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.
-
    
-
    
-We DISLIKE the use of gets(3). Use fgets(3) instead.
-
    
-
    
-We tend to DISLIKE the blatant use of tarballs in an attempt to simply get
+
    We DISLIKE the use of varargs.h. Use stdarg.h instead.
    
+
    We DISLIKE the use of gets(3). Use fgets(3) instead.
    
+
    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.md file.
+tarball MUST be explained in the remarks.md file.
    
+
    
+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.
 
    
 
    On 28 January 2007, the Judges rescinded the requirement that the
 # in a C preprocessor directive must be the 1st non-whitespace byte.
    
@@ -1647,19 +1397,15 @@ 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.
    
-
    
-While those who are used to temperatures found on dwarf
+
    While those who are used to temperatures found on dwarf
 planets
 (yes Virginia, dwarf planets ARE planets!), such as
 Pluto, 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.
-
    
-
    
-One line programs should be short one line programs: say around 80 to 132
+whether pigs have wings is likely to remain a debatable point to most.
    
+
    One line programs should be short one line programs: say around 80 to 132
 bytes long. Going well beyond 132 bytes is a bit too long to be called
-a one-liner in our vague opinion.
-
    
+a one-liner in our vague opinion.
    
 
    We tend to DISLIKE programs that:
    
 
      
 
    • are very hardware specific
      • 
@@ -1667,53 +1413,30 @@ a one-liner in our vague opinion.
 sockets/streams specific code is likely not to be)
 
    • dump core or have compiler warnings (it is OK only if
 you warn us in your remarks.md file)
      • 
-
    • 
-won’t compile or run in a Single UNIX
+
    • won’t compile or run in a Single UNIX
 Specification
-environment
-
      • 
-
    • 
-depend on a utility or application not normally found
+environment
      • 
+
    • depend on a utility or application not normally found
 in systems that conform to the Single UNIX
-Specification
-
      • 
-
    • abuse the build file to get around the size limit
      • 
-
    • 
-obfuscate by use of ANSI trigraphs
-
      • 
-
    • 
-obfuscate by use of digraphs
-
      • 
-
    • 
-are larger than they need to be
-
      • 
-
    • 
-have more lines than they need to have
-
      • 
-
    • 
-are “blob-ier” (just a pile of unformatted C code)
-than they need to be
-
      • 
-
    • 
-are rather similar to previous
-winners :-(
-
      • 
-
    • 
-are identical to previous
-losers :-)
-
      • 
+Specification
+
    • abuse the build file to get around the size limit
      • 
+
    • obfuscate by use of ANSI trigraphs
      • 
+
    • obfuscate by use of digraphs
      • 
+
    • are larger than they need to be
      • 
+
    • have more lines than they need to have
      • 
+
    • are “blob-ier” (just a pile of unformatted C code) than they need to be
      • 
+
    • are rather similar to previous winners :-(
      • 
+
    • are identical to previous losers :-)
      • 
 
    • that mandate the exclusive use of a specific Integrated Development Environment (IDE)
      • 
 
    
 
    In order to encourage submission portability, we DISLIKE submissions 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.
    
-
    
-The program must compile and link cleanly in a Single UNIX
+
    The program must compile and link cleanly in a Single UNIX
 Specification
 environment. Therefore do not assume the system has a
-windows.h include file:
-
    
+windows.h include file:
    
 
        #include <windows.h>  /* we DISLIKE this */
    
 
    Unless you are cramped for space, or unless you are entering the
 ‘Best one liner’ category, we suggest that you format your program
@@ -1730,29 +1453,21 @@ is quite another to use many bytes of -Ds in order to try and squee
 source under the size limit.
    
 
    Your source code, post-pre-processing, should not exceed the size of
 Microsoft Windows. :-)
    
-
    
-Other windows, on the other hand, might be OK: especially where “X
+
    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). :-)
-
    
-
    
-The IOCCC judges, as a group, have a history giving wide degree of latitude
+“unseen” (i.e., not dirty). :-)
    
+
    The IOCCC 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 on Earth. :-)
-
    
-
    
-You should try to restrict commands used in the build file to commands found in
+variation as it is possible to have on Earth. :-)
    
+
    You should try to restrict commands used in the build file to commands found in
 Single UNIX
 Specification
 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
+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.
-
    
+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, etc.).
    
 
    
@@ -1782,25 +1497,25 @@ bytes. REALLY TRY to be more creative than blob coding. 
 
    We really DISLIKE submissions that make blatant use of including
 large data files to get around the source code size limit.
    
-
    We do not recommend submitting systemd source code to the IOCCC,
+
    
+We do not recommend submitting systemd source code to the IOCCC,
 if nothing else because that code is likely to exceed the source code
 size limit. This isn’t to say that another highly compact and obfuscated
-replacement of init would not be an interesting submission.
    
+replacement of init(8) would not be an interesting submission.
+
    
 
    Did we remember to indicate that programs that blatantly use
 some complex state machine to do something simple, are boring?
 We think we did. :-)
    
 
    
 
    All generalizations are false, including this one. – Mark Twain
    
 
    
-
    
-Given two versions of the same program, one that is a compact blob
+
    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 the IOCCC
-rules for details (in particular, Rule 9).
-
    
+rules for details (in particular, Rule 9).
    
 
    We suggest that you avoid trying for the ‘smallest self-replicating’
 source. The smallest, a zero byte entry, won in
 1994.
    
@@ -1810,25 +1525,17 @@ they do not work as documented.
    
 
    Please note that the C source below, besides lacking in obfuscation,
 is NOT the smallest C source file that when compiled and run, dumps core:
    
 
        main;
    
-
    
-Unless you specify -fwritable-strings (see COTHER in the example
+
    Unless you specify -fwritable-strings (see COTHER in the example
 Makefile, described in the Makefile section), do not assume this
-sort of code will work:
-
    
+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:
-
    
+
    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 */
    
-
    
-There are more than 1 typos in this very sentence.
-
    
+
    There are more than 1 typos in this very sentence.
    
 
    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.
@@ -1840,51 +1547,35 @@ 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
+
    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.
-
    
+some way or another.
    
 
    This could be the only guideline that contains the word
 fizzbin.
    
-
    
-However, do you know how to play fizzbin?
-You do?!? (Except on Tuesday?)
-
    
-
    
-OK, there are actually 2 guidelines that contain the word
+
    However, do you know how to play fizzbin?
+You do?!? (Except on Tuesday?)
    
+
    OK, there are actually 2 guidelines that contain the word
 fizzbin,
-unless you count this one, in which case there are 3. :-)
-
    
+unless you count this one, in which case there are 3. :-)
    
 
    We DISLIKE submissions that use proprietary toolkits such as the M*tif,
 Xv*ew, or OpenL*ok toolkits, since not everyone has them. Use an
 open source toolkit that is widely and freely available instead.
    
 
    NOTE: The previous guideline in this spot has been replaced by this guideline:
    
-
    
-X client submissions should try to not to depend on particular items in
+
    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. They should also not depend on any
-particular window manager.
-
    
-
    
-Try to avoid submissions that play music that some people believe is copyrighted
-music.
-
    
-
    
-While we recognize that UNIX is not a universal operating system, the contest
+particular window manager.
    
+
    Try to avoid submissions that play music that some people believe is copyrighted
+music.
    
+
    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.
-
    
-
    
-You are well advised to submit code that conforms to the Single UNIX
-Specification Version 4.
-
    
-
    
-To quote the IOCCC judges:
-
    
+Specification.
    
+
    You are well advised to submit code that conforms to the Single UNIX
+Specification Version 4.
    
+
    To quote the IOCCC judges:
    
 
    
 
    You very well might not be completely prohibited from failing to not partly
 misunderstand this particular guideline, but of course, we could not possibly
@@ -1909,23 +1600,17 @@ parliament should you have one.
    
 
    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.
    
-
    
-You are better off explaining what your submission does in your
+
    You are better off explaining what your submission does in your
 remarks.md file section rather than leaving it obscure for the
 IOCCC judges as we might miss something and/or be too tired to
-notice.
-
    
-
    
-Please avoid this specific individual guideline, if it at all possible.
-
    
-
    
-We freely admit that interesting, creative or humorous comments in
+notice.
    
+
    Please avoid this specific individual guideline, if it at all possible.
    
+
    We freely admit that interesting, creative or humorous comments in
 your remarks.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
 your remarks.md content during the judging process, so it is worth your
-while to write a remarkable remarks.md file.
-
    
+while to write a remarkable remarks.md file.
    
 
    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.
@@ -1935,15 +1620,15 @@ prevent such trailing control-M’s being added.
    
 
    One should restrict libcurses to portable features found on BSD
 or Linux curses.
    
 
    
-Rule 13 no longer discourages the use of UTF-8
-characters in C code.
+If you do #include <curses.h> make CERTAIN you link in curses (i.e.
+-lcurses) and not ncurses (i.e. -lncurses).
 
    
-
    
-It is a very good idea to, in your remarks.md file, tell us why you
+
    Rule 13 no longer discourages the use of UTF-8
+characters in C code.
    
+
    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!
-
    
+otherwise overlook. <<– Hint!
    
 
    Anyone can format their code into a dense blob. A really clever
 author will try format their submission using a “normal” formatting style
 such that at first glance (if you squint and don’t look at the details)
@@ -1955,38 +1640,31 @@ suggest you remark on this point in your remarks.md where you talk
 about why you think your submission is obfuscated. On the other hand,
 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 prefer code that can run on either a 64-bit or 32-bit
+
    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**.
-
    
+some Intel-like x86 architecture**.
    
 
    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.
    
-
    
-The IOCCC size tool source is not an original work, unless you are Anthony C
+
    The IOCCC size tool source is not an original work, unless you are Anthony C
 Howe, in which case it is original! :-)
 Submitting source code that uses the contents of
 iocccsize.c,
 unless you are Anthony C Howe, might run the
-risk of violating Rule 7.
-
    
-
    
-The IOCCC submission tarball validator source is not an original work,
+risk of violating Rule 7.
    
+
    The IOCCC submission tarball validator source is not an original work,
 unless you are Cody Boone Ferguson, in
 which case it is original! :-) Submitting source code that uses the contents of
 txzchk.c,
 unless you are Cody Boone Ferguson, might
-run the risk of violating Rule 7.
-
    
-
    
-In addition to the above tools, none of the mkiocccentry
+run the risk of violating Rule 7.
    
+
    In addition to the above tools, none of the mkiocccentry
 tools, including, but not
 limited to
 mkiocccentry,
-chkentry,
+chksubmit,
 chksubmit,
 fnamchk
 and
@@ -2004,28 +1682,22 @@ are original! :-) Submitting source code that uses the content of any of these t
 library, unless you are Cody Boone
 Ferguson or Landon Curt
 Noll, might run the risk of violating
-Rule 7.
-
    
-
    
-And unless you are Landon Curt Noll,
+Rule 7.
    
+
    And unless you are Landon Curt Noll,
 the code in
 dbg and
 dyn_array are
 not original works. Submitting source code that uses the contents of those
 libraries, unless you Landon Curt Noll,
-might run the risk of violating Rule 7.
-
    
-
    
-Rule 7 does not prohibit you from writing your own
+might run the risk of violating Rule 7.
    
+
    Rule 7 does not prohibit you from writing your own
 obfuscated versions of these tools, unless of course you are Landon Curt
 Noll, in which case you probably
 won’t win since IOCCC judges should not enter the IOCCC! :-)
 However, if you do write your own version, you might wish to make it do something
 more interesting than simply implementing the IOCCC
-tools’ algorithms.
-
    
-
    
-Even so, we do not recommend you try and submit a JSON parser due to
+tools’ algorithms.
    
+
    Even so, we do not recommend you try and submit a JSON parser due to
 the fact it will likely exceed the source code size limit
 and because you likely can’t beat flex and
 bison in obfuscation. This isn’t to
@@ -2036,34 +1708,25 @@ obfuscate a JSON parser more than flex<
 because of the source code size limit or because it is not
 as obfuscated as the flex and bison
 generated code of
-jparse.
-
    
+jparse.
    
 
    While programs that only run in a specific word size are OK, if you have
 to pick, choose a 64-bit word size.
    
-
    
-If the IOCCC judges are feeling ornery we
+
    If the IOCCC judges are feeling ornery we
 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 :-)
-
    
-
    
-If your submission MUST run only on a 64-bit or 32-bit architecture,
+CPU, we might just try your submission on that emulator as well :-)
    
+
    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 Makefile section). Do not assume a
-processor word size without specifying -arch. For example:
-
    
+processor word size without specifying -arch. For example:
    
 
        ARCH= -m64
    
-
    
-Note, however, that some platforms will not necessarily support some
+
    Note, however, that some platforms will not necessarily support some
 architectures. For instance, more recent versions of macOS do NOT support
-32-bit!
-
    
-
    
-If there are limitations in your submission, you are highly encouraged
+32-bit!
    
+
    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:
-
    
+submission factors values up to a certain size, you might want to state:
    
 
    
 
    This submission factors values up 2305567963945518424753102147331756070.
 Attempting to factor larger values will produce unpredictable results.
    
@@ -2080,9 +1743,7 @@ produce unpredictable results.
    
 2305567963945518424753102147331756070. 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:
-
    
+
    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 and
 2305567963945518424753102147331756070. Attempting to factor anything else
@@ -2109,42 +1770,28 @@ and state:
    
 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 of
+
    Do not fear if you’re not 100% sure of the significance of
 2305567963945518424753102147331756070 as it is not of prime importance: or is
-it? :-)
-
    
-
    
-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
+it? :-)
    
+
    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
+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 IOCCC markdown guidelines
+character tab stop.
    
+
    PLEASE observe our IOCCC 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 19 and our
-FAQ on “markdown”.
-
    
-
    
-We LIKE reading remarks.md files, especially if they contain
+FAQ on “markdown”.
    
+
    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. :-)
-
    
+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. :-)
    
 
    Try to be even more creative!
    
 
    Jump to: top
    
 
    
@@ -2166,31 +1813,24 @@ disqualified. RULE ABUSE CARRIES A CERTAIN LEVEL OF RISK!IOCCC rules and one that
 does.
    
-
    
-If you intend to abuse the IOCCC rules,
+
    If you intend to abuse the IOCCC rules,
 indicate so in your remarks.md file. You MUST try to justify
 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.
 As there is no guarantee that you will succeed, you might consider
 submitting an alternate version that conforms to the
-IOCCC rules.
-
    
-
    
-If you do bypass the mkiocccentry(1) warnings about Rule
+IOCCC rules.
    
+
    If you do bypass the mkiocccentry(1) warnings about Rule
 2a and/or about Rule 2b or any other
 rule and submit a submission anyway, you MUST try to justify why the IOCCC
 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
+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
+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.
@@ -2199,10 +1839,8 @@ 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
 truck through the holes” in the IOCCC rules and IOCCC
-guidelines.
-
    
-
    
-At the risk of stating the obvious, this contest is a parody of the software
+guidelines.
    
+
    At the risk of stating the obvious, this contest is a parody of the software
 development process. The IOCCC rules and IOCCC guidelines
 are only part of the overall contest. Even so, one might think the
 contest IOCCC rules and IOCCC guidelines process as a parody
@@ -2211,20 +1849,17 @@ and what engineering delivers. Real programmers must face obfuscated and
 sometimes conflicting 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.
-
    
+IOCCC guidelines are written in obfuscated form.
    
 
    Jump to: top
    
 
    
 
    JUDGING PROCESS:
    
 
    
 
    Submissions are judged by Leonid A. Broukhis and Landon Curt Noll.
    
-
    
-Each submission submitted is given a random string and subdirectory. The
+
    Each submission submitted is given a random string and subdirectory. The
 submission files including, but not limited to prog.c, Makefile,
 remarks.md, .info.json, .auth.json as well as any data files that you
 submit, are all placed under their own directory and stored and judged from this
-directory.
-
    
+directory.
    
 
    Any information about the authors is not read by the IOCCC judges until
 the judging process is complete, and then only from entries that have
 won an award. Because we do not read this information for entries that
@@ -2232,11 +1867,9 @@ do not win, we do not know who did not win.
    
 
    The above process helps keep us biased for/against any one particular
 individual. Therefore you MUST refrain from putting any information
 that reveals your identity in your submission.
    
-
    
-Now some people point out that coding and/or writing style might reveal the
+
    Now some people point out that coding and/or writing style might reveal the
 information about the authors. However we consider this to be simply
-circumstantial and outside the scope of the above paragraph.
-
    
+circumstantial and outside the scope of the above paragraph.
    
 
    Some people, in the past, have attempted to obfuscate their identity by
 including comments of famous Internet personalities such as Peter
 Honeyman. The IOCCC judges are on to this trick
@@ -2264,15 +1897,11 @@ Because the main ‘prize’ of winning is being announced, we make all
 attempts to send non-winners into oblivion. We remove all non-winning
 files, and shred all related printouts. By tradition, we do not even
 reveal the number of submissions that we receive.
    
-
    
-During the judging process, a process that spans multiple sessions over
+
    During the judging process, a process that spans multiple sessions over
 a few weeks, we post general updates from our Mastodon
-account.
-
    
-
    
-Make sure you reload the feed every so often because unless you
-are mentioned you will NOT get a push notification!
-
    
+account.
    
+
    Make sure you reload the feed every so often because unless you
+are mentioned you will NOT get a push notification!
    
 
    Jump to: top
    
 
    
 
    JUDGING ROUNDS:
    
@@ -2289,12 +1918,8 @@ often more than two.
    
 
    
 
    A reading consists of a number of actions:
    
 
      
-
    • 
-Reading prog.c, the C source and reviewing the remarks.md information
-
      • 
-
    • 
-Briefly looking at any supplied data files
-
      • 
+
    • Reading prog.c, the C source and reviewing the remarks.md information
      • 
+
    • Briefly looking at any supplied data files
      • 
 
    • Passing the source thru the C pre-processor skipping over any #included files
      • 
 
    • Performing a number of C beautify/cleanup edits on the source
      • 
 
    • Passing the beautified source thru the C pre-processor skipping over any #included files
      • 
@@ -2304,13 +1929,9 @@ Briefly looking at any supplied data files
 
    
 
    In later rounds, other actions are performed including performing
 miscellaneous tests on the source and binary.
    
-
    
-This is the very guideline that goes, BING!
-
    
-
    
-Okay, technically that was the second guideline that goes BING, and this
-is the third. :-)
-
    
+
    This is the very guideline that goes, BING!
    
+
    Okay, technically that was the second guideline that goes BING, and this
+is the third. :-)
    
 
    Until we reduce the stack of submissions down to about 25 submissions,
 submissions are judged on an individual basis. A submission is set aside because it
 does not, in our opinion, meet the standard established by the round.
@@ -2327,11 +1948,8 @@ we receive. A typical category list might be:
    
 
  • best game that is obfuscated
    • 
 
  • most creatively obfuscated program
    • 
 
  • most deceptive C code (code with deceptive comments and source code)
    • 
-
  • 
-best X program (see OUR LIKES AND DISLIKES
-and the
-FAQ on “Xorg being deprecated”)
-
    • 
+
  • best X program (see OUR LIKES AND DISLIKES and the FAQ on “Xorg
+being deprecated”)
    • 
 
  • best abuse of ISO C or ANSI C standard (see above about compilers)
    • 
 
  • best abuse of the C preprocessor
    • 
 
  • worst/best abuse of the rules (or some variation)
    • 
@@ -2352,23 +1970,22 @@ similar, but slightly better submission. For this reason, it is sometimes
 worthwhile to resubmit an improved version of a submission that failed to win in
 a previous year, the next year. This assumes, of course, that the submission is
 worth improving in the first place!
    
-
    
-Over the years, more than one IOCCC judge
+
    Over the years, more than one IOCCC judge
 has been known to bribe another IOCCC judge into voting for a
 winning submissions by offering a bit of high quality chocolate, or
-other fun item.
-
    
+other fun item.
    
 
    
-One should NOT attempt to bribe an IOCCC
+Over the years some judges have submitted code that had to be rejected once it
+was discovered to be a judge.
+
    
+
    One should NOT attempt to bribe an IOCCC
 judge, unless you are an IOCCC judge,
 because bribing an IOCCC judge by a non-judge
 has been shown to NOT be effective when the person attempting
 the bribe is made known to the IOCCC judges
 (i.e., they are not anonymous) AND/OR the bribe is otherwise
-associated with a submission to the IOCCC.
-
    
-
    
-With the previous guideline in mind: anonymous gifts
+associated with a submission to the IOCCC.
    
+
    With the previous guideline in mind: anonymous gifts
 for the IOCCC judges that are NOT ASSOCIATED
 WITH a submission to the IOCCC may be sent to the
 IOCCC judges via the
@@ -2376,20 +1993,15 @@ WITH a submission to the IOCCC may be sent
 It has been shown that receiving anonymous gifts provides the
 IOCCC judges with a nice
 dopamine boost, and happy
-IOCCC judges help make the IOCCC better for everyone. :-)
-
    
-
    
-See the
-FAQ on “supporting the IOCCC”.
-
    
+IOCCC judges help make the IOCCC better for everyone. :-)
    
+
    See the
+FAQ on “supporting the IOCCC”.
    
 
    More often than not, we select a small submission (usually one line) and a
 strange/creative layout submission. We sometimes also select a
 submission that abuses the IOCCC guidelines in an interesting way,
 or that stretches the contest rules that while legal, it
 nevertheless goes against the intent of the rules.
    
-
    
-Nevertheless, see Rule 12.
-
    
+
    Nevertheless, see Rule 12.
    
 
    In the end, we traditionally pick one submission as ‘best’. Sometimes such
 a submission simply far exceeds any of the other submissions. More often, the
 ‘best’ is picked because it does well in a number of categories.
    
@@ -2400,44 +2012,28 @@ Winning source is called prog.c. A compiled binary is called 
 
    
 
    ANNOUNCEMENT OF WINNERS:
    
 
    
-
    
-The IOCCC judges will toot initial announcement of who won, the name
+
    The IOCCC judges will toot initial announcement of who won, the name
 of their award, and a very brief description (award title) of the winning entry
-from the @IOCCC Mastodon account.
-
    
-
    
-We recommend that you follow us on mastodon but please make sure to
+from the @IOCCC Mastodon account.
    
+
    We recommend that you follow us on mastodon but please make sure to
 refresh the feed every so often (if not more often) because unless you are
-mentioned or someone boosts your post you will not get a push notification.
-
    
+mentioned or someone boosts your post you will not get a push notification.
    
 
    Jump to: top
    
 
    
 
    How the new IOCCC winners will be announced
    
 
    
-
    
-The current status of the IOCCC will change from
-judging to closed .
-
    
-
    
-The contest_status in the status.json file will change
-from judging to closed as well.
-
    
-
    
-When the above happens, the winning entries have been selected by the IOCCC
-judges.
-
    
-
    
-The IOCCC judges will begin to prepare to release the source
-code of the new IOCCC winners.
-
    
-
    
-The IOCCC judges will commit the winning source to the
+
    The current status of the IOCCC will change from
+judging to closed .
    
+
    The contest_status in the status.json file will change
+from judging to closed as well.
    
+
    When the above happens, the winning entries have been selected by the IOCCC
+judges.
    
+
    The IOCCC judges will begin to prepare to release the source
+code of the new IOCCC winners.
    
+
    The IOCCC judges will commit the winning source to the
 IOCCC winner repo which will update the
-Official IOCCC website.
-
    
-
    
-The IOCCC news will also contain an announcement of the winners.
-
    
+Official IOCCC website.
    
+
    The IOCCC news will also contain an announcement of the winners.
    
 
    Jump to: top
    
 
    
 
    An important update to how winners are announced
    
@@ -2454,27 +2050,21 @@ In addition a note is posted to the IOCCC
 
    
 We will also post a notice to the IOCCC discord server.
 
    
-
    
-Consider joining the IOCCC discord community via this link:
-https://discord.gg/Wa42Qujwnw
-
    
+
    Consider joining the IOCCC discord community via this link:
+https://discord.gg/Wa42Qujwnw
    
 
    Jump to: top
    
 
    
 
    Back to announcement of winners
    
 
    
-
    
-It is pointless to ask the IOCCC judges how many
+
    It is pointless to ask the IOCCC judges how many
 submissions we receive. See How many submissions do the judges receive for a
-given IOCCC?.
-
    
-
    
-Often, winning entries are published in selected magazines from around the
+given IOCCC?.
    
+
    Often, winning entries are published in selected magazines from around the
 world. Winners have appeared in books (‘The New Hacker's Dictionary’,
 ‘Obfuscated C and Other Mysteries’, ‘Pointers On C’, others) and on t-shirts
 (sometimes by the author(s) themselves). There have been multiple classes
 that have focused in part, on IOCCC winning entries. And more than one winner has been turned
-into a tattoo!
-
    
+into a tattoo!
    
 
    Last, but not least, winners receive international fame and flames! :-)
    
 
    Jump to: top
    
 
    
@@ -2482,43 +2072,29 @@ into a tattoo!
 
    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.
-
    
-
    
-PLEASE be sure you have the current IOCCC rules and
-IOCCC guidelines prior to submitting to the contest.
-
    
+
    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.
    
+
    PLEASE be sure you have the current IOCCC rules and
+IOCCC guidelines prior to submitting to the contest.
    
 
    See the Official IOCCC website news for additional information.
    
-
    
-For the updates and breaking IOCCC news, you are encouraged to follow
+
    For the updates and breaking IOCCC news, you are encouraged to follow
 the IOCCC on Mastodon. See our
 FAQ on “Mastodon”
 for more information. Please do note that unless
 you are mentioned by us you will NOT get a notification from the app so you
-should refresh the page even if you do follow us.
-
    
-
    
-Check out the Official IOCCC winner website in general.
-
    
-
    
-Consider joining the IOCCC discord community via this link:
-https://discord.gg/Wa42Qujwnw
-
    
-
    
-See the
+should refresh the page even if you do follow us.
    
+
    Check out the Official IOCCC winner website in general.
    
+
    Consider joining the IOCCC discord community via this link:
+https://discord.gg/Wa42Qujwnw
    
+
    See the
 FAQs on “obtaining, compiling, installing and using the mkiocccentry tools”
 and the
 FAQ on “how to enter the IOCCC”
 as that FAQ has important details on
 how to register
 as well as
-how to upload your submission for the IOCCC.
-
    
+how to upload your submission for the IOCCC.
    
 
    
 
    Jump to: top
 
    
diff --git a/next/guidelines.md b/next/guidelines.md
index d8332e8f9..ba460adf9 100644
--- a/next/guidelines.md
+++ b/next/guidelines.md
@@ -48,13 +48,11 @@ Jump to: [top](#)
 
    
 
 
    
-These [IOCCC guidelines](guidelines.html) are version **28.48 2025-09-28**.
+These [IOCCC guidelines](guidelines.html) are version **28.49 2025-11-17**.
 
    
 
-
    
 The markdown form of these guidelines is available for download.
-
    
 
 **IMPORTANT**: Be **SURE** to read the [IOCCC rules](rules.html).
 
@@ -93,11 +91,9 @@ about them.  The [IOCCC guidelines](guidelines.html) should be viewed as
 allowed_.  Even so, you are safer if you remain within the [IOCCC
 guidelines](guidelines.html).
 
-
    
 Of course if a guideline is talking about a rule and you break that guideline,
 you stand a good chance of having your submission rejected for breaking the
 rule, not the guideline.
-
    
 
 You **SHOULD read the CURRENT [IOCCC rules](rules.html)**, _prior_ to submitting
 code to the contest.
@@ -131,68 +127,51 @@ This contest will enter the **[judging](../faq.html#judging)** state on **2025-0
 When this happens, you may no longer upload your submissions to the IOCCC.
 
    
 
-
    
 **IMPORTANT NOTE**: Until the contest enters the **[open](../faq.html#open)** state, any or all
 of the above **dates and times may change _AT ANY TIME_**!
-
    
 
 
    
 The reason for the times of day are so that key IOCCC events are **calculated**
 to be a **fun**ctional UTC time.  :-)
 
    
 
-
    
 Until the contest status becomes **[open](../faq.html#open)**,
 the [IOCCC rules](rules.html),
 [IOCCC guidelines](guidelines.html) and the tools in the
 [mkiocccentry repo](https://github.com/ioccc-src/mkiocccentry) **SHOULD be
 considered** provisional **BETA** versions and **may be adjusted _AT ANY TIME_**
 before the contest status becomes **[open](../faq.html#open)**.
-
    
 
-
    
 See the
 FAQ on "[how to register and submit to the IOCCC](../quick-start.html#enter)"
 for instructions on registering and participating in the IOCCC, as the process
 may change from contest to contest.
-
    
 
-
    
 To assist in the formation of the xz compressed tarball for submission, use the
 `mkiocccentry(1)` tool as found in the [mkiocccentry repo](https://github.com/ioccc-src/mkiocccentry).
-
    
 
-
    
 See FAQs regarding:
-
    
 
 - [obtaining the latest mkiocccentry tools](../faq.html#obtaining_mkiocccentry)
 - [compiling the mkiocccentry tools](../faq.html#compiling_mkiocccentry)
 - [installing the mkiocccentry tools](../faq.html#install)
 - [using the mkiocccentry tools](../faq.html#using_mkiocccentry)
 
-
    
 Uploading a tarball not formed by `mkiocccentry(1)` puts you at a very big risk of
 violating [Rule 17](rules.html#rule17), especially as `mkiocccentry(1)` does a
 great number of things that are required, and it also runs many checks, and if
 any of those checks fail, you are at a very great risk of having your submission
 rejected for violating [Rule 17](rules.html#rule17).
-
    
 
-
    
 We **STRONGLY** recommend you **do** install the
 [mkiocccentry toolkit](https://github.com/ioccc-src/mkiocccentry).
-
    
 
-
    
 **IMPORTANT NOTE**: the tools that require other tools, `mkiocccentry(1)` and
 `txzchk(1)`, will, as of version `2.0.2 2025-03-11`, search under `$PATH`. If
 you have an earlier version and you have not installed the tools and run the
 tools from outside the repo directory, you will have to use the options to the
 tools to set the path to the required tools.
-
    
 
-
    
 See the
 FAQ on "[obtaining and compiling the most recent mkiocccentry tools](../faq.html#mkiocccentry)"
 and the
@@ -201,79 +180,65 @@ as that FAQ has important details on
 [how to register](../next/register.html)
 as well as
 [how to upload your submission](../next/submit.html) to the IOCCC.
-
    
 
-
    
-See also the
-FAQ on "[what the minimum required versions are for this
-contest](../faq.html#minimum_versions)"
-for more details on how to verify you have the correct versions for this
-contest.
-
    
-
-
    
 While the contest is **[open](../faq.html#open)**, you may modify your
 previously uploaded submission by rebuilding your submission with the
 `mkiocccentry(1)` tool and then re-uploading it to **the same slot number** on the
 [submit server](https://submit.ioccc.org).
-
    
 
-
    
 **HINT:** so that you do not have to repeatedly answer all the
 questions, the `mkiocccentry(1)` tool has the options `-a answers`, `-A answers`
 and `-i answers`, where `-a` will write to an answers file (if it does not
 already exist), `-A` **WILL OVERWRITE THE FILE** and `-i` will read the answers from
 the file. If you use `-A`, **BE SURE** you don't overwrite another file by accident!
-
    
 
-
    
 Be aware that even with the `-i answers` you will still be required to confirm
 most if not all `y/n` questions - you just don't have to input the name of the
 submission, the abstract, the author details etc. If you really wish to
 circumvent this you can use the `-Y` option but we do not recommend this because
 if your update breaks a rule or there is some problem, you might not see it.
-
    
 
-
    
 To help with not having to repeatedly enter a UUID, whether for the same
 submission or multiple submissions, you can use the `-u uuidfile` or `-U UUID`
 option. See the
 FAQ on "[how to avoid re-entering your UUID](../faq.html#uuid)"
 for more details. Note that the `-i answers` option cannot be used with the UUID
 options as the answers file includes the UUID.
-
    
 
-
    
 The overall size limit (see [Rule 2a](rules.html#rule2a)) on `prog.c` has been
 **increased from 4096 to 4993** bytes.
 The [Rule 2a](rules.html#rule2a) size was changed from
 **4096** to **4993** to keep the "2b to 2a" size ratio to a
 value similar to the [2001-2012](../faq.html#size_rule2001-2012) and
 [2013-2020](../faq.html#size_rule2013-2020) IOCCC eras.
-
    
 
-
    
 The [Rule 2b](rules.html#rule2b) size has **increased from 2053 to 2503**
 bytes.
+
+
    
+However, you should pay especial attention to our remarks in the [IOCCC28
+index.html](../2024/index.html):
 
    
 
 
    
+> **IMPORTANT HINT**: Only 3 of the 23 **IOCCC28 winners** came close to the
+[Rule 2 size limit](../next/rules.html#rule2).  Large code size isn't
+everything.  :-) Those submitting to future contents should **take a careful
+note** of that fact.
+
    
+
+
 Your submission must satisfy **BOTH** the maximum size
 [Rule 2a](rules.html#rule2a) **AND** the IOCCC size [Rule 2b](rules.html#rule2b).
-
    
 
-
    
 To check your code against [Rule 2](rules.html#rule2), use the `iocccentry(1)` tool.
 For example:
-
    
 
 ``` 
     iocccsize prog.c
 ```
 
-
    
 The IOCCC size tool 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
@@ -284,29 +249,21 @@ 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.  This is a **feature**, not a bug!
-
    
 
-
    
 In cases where the above summary and the algorithm implemented by
 the IOCCC size tool `iocccsize(1)` conflict, the algorithm implemented
 by the current version of `iocccsize(1)` is preferred by the [IOCCC judges](../judges.html).
-
    
 
-
    
 In other words, make sure `iocccsize` does not flag any issues with your
 `prog.c`.
-
    
 
-
    
 There are at least 2 other reasons for selecting 2503 as the 2nd limit besides
 the fact that 2503 is a prime. These reasons may be searched for and discovered
 if you are ["Curios!" about 2503](https://t5k.org/curios/page.php/2503.html).
 :-) Moreover, 2053 was the number of the kernel disk pack of one of the judge's
 BESM-6, and 2503 is a decimal anagram of 2053.
-
    
 
 Take note that this secondary limit imposed by the IOCCC size tool
 obviates some of the need to `#define` C reserved words in an effort
@@ -314,11 +271,12 @@ to get around the size limits of [Rule 2](rules.html#rule2).
 
 Yes Virginia, **that is a hint**!
 
-
    
 The **official locale** of the **IOCCC** is **C**.
-
    
 
 
    
+Did you really think anything else? :-)
+
    
+
 The [mkiocccentry toolkit](https://github.com/ioccc-src/mkiocccentry),
 as of [Release version 2.4.4 2025-03-15](https://github.com/ioccc-src/mkiocccentry/releases/tag/2.4.4),
 will run with a locale set to **C**.
@@ -370,7 +328,6 @@ often award '**Best abuse of the [rules](rules.html)**' or '**Worst abuse of the
 [rules](rules.html)**' or some variation to a submission that illustrates this
 point in an ironic way.
 
-
    
 The IOCCC has a rich history of remarkable winning entries created by
 authors who skillfully employed various techniques to develop their code.
 While it is **NOT** required, you are allowed to use tools to develop
@@ -380,76 +337,57 @@ runtime analysis tools, machine learning tools, natural language models,
 code copilot tools, so-called AI services, large language models (LLMS), etc.
 If you do make use of such tools or services, then we **ENCOURAGE you to describe
 how you used such tools** in your `remarks.md` file.
-
    
 
-
    
 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** them 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`, and other tools found in
 [Single UNIX Specification](https://en.wikipedia.org/wiki/Single_UNIX_Specification)
 environments and systems that conform to the [Single UNIX
 Specification](https://en.wikipedia.org/wiki/Single_UNIX_Specification)
 in the building and compiling of your submission.
-
    
 
 We do realize that there are holes in the [rules](rules.html), and invite
 submitters to attempt to exploit them.  We may award '**Worst abuse of the
 [rules](rules.html)**' or '**Best abuse of the [rules](rules.html)**' or some
 variation and then plug the hole next year.
 
-
    
 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.  :-)
-
    
 
-
    
 There may be fewer than 2^7+1 reasons why these [IOCCC
 guidelines](guidelines.html) seem obfuscated.
-
    
 
-
    
 **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 BETTER** off
 documenting such bugs and/or mis-features in your `remarks.md` file.
-
    
 
-
    
 Consider an example of a [prime number](https://en.wikipedia.org/wiki/Prime_number)
 printing program that claims that 16 is a prime number.
 Noting such a bug in your `remarks.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](https://en.wikipedia.org/wiki/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,
@@ -470,29 +408,20 @@ Jump to: [top](#)
 # `mkiocccentry`
    -

    [Rule 17](rules.html#rule17) (the `mkiocccentry(1)` rule) states that you **REALLY SHOULD** use the `mkiocccentry(1)` tool to package your submission tarball. -

    -

    See the [mkiocccentry repo](https://github.com/ioccc-src/mkiocccentry) for the `mkiocccentry(1)` tool and below for more details. -

    -

    **IMPORTANT NOTE**: make **CERTAIN** you have the most recent version of the `mkiocccentry` toolkit! See the FAQ on "[obtaining the mkiocccentry toolkit](../faq.html#obtaining_mkiocccentry)". -

    -

    `mkiocccentry` runs a number of checks, by the tool itself and by executing other tools, _before_ packaging your xz compressed tarball, including running `chksubmit(1)` on the submission directory. -

    -

    If `mkiocccentry` encounters an **error**, the program will exit and the xz compressed tarball **will not be formed**. For instance, if [chksubmit](#chksubmit) fails to validate the submission directory, either because @@ -504,60 +433,45 @@ mkiocccentry bug report page](https://github.com/ioccc-src/mkiocccentry/issues/new?assignees=&labels=bug&projects=&template=bug_report.yml&title=%5BBug%5D+%3Ctitle%3E). **PLEASE run the `bug_report.sh` script to help us out here!** See the FAQ on "[reporting mkiocccentry bugs](../faq.html#mkiocccentry_bugs)". -

    -

    Once the tarball is packaged it will run `txzchk(1)`, which will also run `fnamchk(1)`, as part of its algorithm. -

    -

    However, even if `mkiocccentry` or one of the tools it invokes reports an error, it **does not** necessarily mean it is a bug in the code. It might be an issue with your submission. Thus if you report an error as a bug it might not be something that will be fixed as there might not be anything wrong with the tools. -

    -

    On the other hand, some conditions flagged by `mkiocccentry(1)` are **warnings** and it allows you to override these, if you wish. If you're brave enough you can use the `-W` option to ignore all warnings but this is a big risk; the `-y` option will assume '_yes_' to most questions but this is also a big risk. Using `-Y` will say '_yes_' to even more prompts. Needless to say, we do **NOT** recommend these options. -

    -

    In many places it will prompt you to verify what you input, allowing you to correct details as you go along. Be advised that there is a default answer and if you press enter it will proceed with that default, so make sure you have provided the correct answer. -

    -

    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` option to `mkiocccentry` for the tool to pseudo-randomly create answers for you. For example: -

    ``` mkiocccentry -d workdir topdir ``` -

    **IMPORTANT NOTE**: if you run an IOCCC related tool outside the repo directory (specifying the absolute or relative path to the tool) and you have not installed the tools (and we **STRONGLY** recommend you **do** install them), then you will have to specify the options (such as paths) for the tools that are required like `chksubmit(1)`, `txzchk(1)` and `fnamchk(1)`. -

    -

    Make sure you have the latest version of of the [mkiocccentry toolkit](https://github.com/ioccc-src/mkiocccentry) so that you do not violate [Rule 17](rules.html#rule17) by mistake. -

    Jump to: [top](#) @@ -567,24 +481,19 @@ Jump to: [top](#) ## `mkiocccentry(1)` synopsis
    -

    The synopsis of the `mkiocccentry(1)` tool is: -

    ``` mkiocccentry [options] workdir topdir ``` -

    To help you with editing a submission, the `mkiocccentry(1)` tool has some options to write _OR_ read from an answers file so you do not have to input the information about the author(s) and the submission more than once, unless of course you need to make some changes, in which case you can use the option that overwrites the file. If you do use the overwrite option, **MAKE SURE** you do not overwrite another file! -

    -

    See the FAQ on the "[mkiocccentry tool](../faq.html#mkiocccentry)" @@ -592,107 +501,88 @@ for how to use this tool and the FAQ on the "[finer details of mkiocccentry](../faq.html#mkiocccentry_details)" for even more information. -

    # Other mkiocccentry tools
    -

    The `mkiocccentry(1)` tool will execute a number of tools, some of which will execute one or more additional tools. -

    ## `iocccsize`
    -

    `mkiocccentry(1)` will use code from `iocccsize(1)` which detects a number of issues (such as [Rule 2](rules.html#rule2)) that you may ignore, if you wish, as noted above. -

    -

    In other words, you no longer need to run `iocccsize` manually. However, the checks described above are still made but through the `mkiocccentry(1)` tool itself. -

    - Jump to: [top](#) -
    -## `chkentry` +
    +## `chksubmit`
    -

    `mkiocccentry(1)` will write two JSON files: `.auth.json` and +`mkiocccentry(1)` will write two JSON files: `.auth.json` and `.info.json`. These files contain information about the author(s) and about the -submission. After these files are formed, the `chkentry(1)` tool will be run on +submission. After these files are formed, the `chksubmit(1)` tool will be run on the submission directory; this tool not only validates the two JSON files (and runs specific checks on them after validating the JSON), but it also verifies that what is in the manifest in `.info.json` matches the contents of -the directory, in addition to other checks. If `chkentry(1)` fails to validate +the directory, in addition to other checks. If `chksubmit(1)` fails to validate anything at all, your submission **WILL BE** rejected! -

    -

    -**IMPORTANT**: although `chkentry(1)` validates the files in the directory, it +**IMPORTANT**: although `chksubmit(1)` validates the files in the directory, it only inspects the contents of the two JSON files; it performs other kinds of checks on the other files, and those checks are run on the two JSON files as well. -

    -

    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 such invalid JSON files, **PLEASE** document and explain this in your `remarks.md` file. -

    -If `chkentry` does not pass and you used `mkiocccentry(1)` it is **very likely** a +On the other hand, some people might question what actually constitutes a valid +JSON file. :-) +

    + +If `chksubmit` does not pass and you used `mkiocccentry(1)` it is **very likely** a bug and you should [report it as a bug at the mkiocccentry issues page](https://github.com/ioccc-src/mkiocccentry/issues/new?assignees=&labels=bug&projects=&template=bug_report.yml&title=%5BBug%5D+%3Ctitle%3E). **PLEASE** run the command: -

    ``` make bug_report ``` -

    from the top level repo directory itself and attach the bug report file (it will tell you the name of the file). See also the FAQ on "[reporting mkiocccentry bugs](../faq.html#mkiocccentry_bugs)". -

    -

    -Assuming that `chkentry(1)` successfully validates your submission directory, +Assuming that `chksubmit(1)` successfully validates your submission directory, the tarball will be formed and then `txzchk(1)` will be executed on it. In this case, there should be no problems, as `mkiocccentry(1)` should **NOT** form a tarball if there are any issues. -

    -

    -If `mkiocccentry(1)` is used and `chkentry(1)` fails to validate your submission +If `mkiocccentry(1)` is used and `chksubmit(1)` fails to validate your submission directory, then unless it is a system specific problem, it could be a bug in -`mkiocccentry(1)`, `chkentry(1)` or possibly `jparse`, although this is unlikely. +`mkiocccentry(1)`, `chksubmit(1)` or possibly `jparse`, although this is unlikely. Nonetheless, if you believe there is a bug, you may report it as explained above. -

    -

    If you want to know what `.auth.json` is, see the FAQ on "[.auth.json](../faq.html#auth_json)". If you want to know what the `.info.json` file is, see the FAQ on "[.info.json](../faq.html#info_json)". -On the other hand, if you want to know a bit more details about `chkentry(1)`, see the -FAQ about "[chkentry](../faq.html#chkentry)". -

    +On the other hand, if you want to know a bit more details about `chksubmit(1)`, see the +FAQ about "[chksubmit](../faq.html#chksubmit)". -

    -`chkentry` uses the `jparse` library. See the +`chksubmit` uses the `jparse` library. See the [jparse README.md](https://github.com/ioccc-src/mkiocccentry/blob/master/jparse/README.md) in the [mkiocccentry GitHub repo subdirectory @@ -702,9 +592,7 @@ file](https://github.com/ioccc-src/mkiocccentry/blob/master/jparse/jparse_librar in the [mkiocccentry GitHub repo subdirectory jparse](https://github.com/ioccc-src/mkiocccentry/tree/master/jparse), for more details. -

    -

    The `jparse` parser, library and tools were co-developed by [Cody Boone Ferguson](../authors.html#Cody_Boone_Ferguson) and [Landon Curt Noll](http://www.isthe.com/chongo/index.html) in 2022-2025 and come from the @@ -712,15 +600,11 @@ Noll](http://www.isthe.com/chongo/index.html) in 2022-2025 and come from the tools use a _clone_** of the [jparse repo](https://github.com/xexyl/jparse) **at a _specific_ release**. Thus the `mkiocccentry` will at times be behind the [jparse repo](https://github.com/xexyl/jparse)! -

    -

    You do **NOT need to install** `jparse` from the [jparse repo](https://github.com/xexyl/jparse)! The `mkiocccentry` tools link in the static library from `mkiocccentry`'s _clone_. -

    -

    The `mkiocccentry` toolkit _also_ has a clone of _both_ the [dbg library](https://github.com/lcn2/dbg) and the [dyn_array library](https://github.com/lcn2/dyn_array); the [dyn_array @@ -729,30 +613,27 @@ library](https://github.com/lcn2/dbg) and the [jparse library](https://github.com/xexyl/jparse) uses both libraries but unlike in the [jparse repo](https://github.com/xexyl/jparse), the libraries do not need to be installed separately, in order to use the tools in `mkiocccentry`. -

    -

    In other words, `mkiocccentry` **contains everything** you need, and _even if you do install_ the libraries from their respective repos, it/they will **not be used** when compiling the `mkiocccentry` tools. This is important to make sure that you're using the correct versions, which is also verified by -`chkentry` (in the JSON files created by `mkiocccentry(1)`). See [Rule +`chksubmit` (in the JSON files created by `mkiocccentry(1)`). See [Rule 17](rules.html#rule17)! -

    +We **HIGHLY** recommend you install the `mkiocccentry` toolkit, however. +

    + Please see the -FAQ on "[validating your submission directory](../faq.html#chkentry) -for more details on `chkentry(1)`. -

    +FAQ on "[validating your submission directory](../faq.html#chksubmit) +for more details on `chksubmit(1)`. -

    You might also wish to see the FAQ on "[.auth.json](../faq.html#auth_json)" and the FAQ on "[.info.json](../faq.html#info_json)" for much more information on these files. -

    Jump to: [top](#) @@ -762,7 +643,6 @@ Jump to: [top](#) ## `txzchk`
    -

    `txzchk(1)` performs a wide number of sanity checks on the xz compressed tarball; if any issues are found ('`feathers are stuck in the tarball`' :-) ) **AND if and _ONLY IF_ you used `mkiocccentry(1)`**, then it is **possibly** a @@ -772,109 +652,93 @@ page](https://github.com/ioccc-src/mkiocccentry/issues/new?assignees=&labels=bug **PLEASE run the `bug_report.sh` script to help us out here!** You may do this by running from the top level directory of the repo `make bug_report`. See the FAQ on "[reporting mkiocccentry bugs](../faq.html#mkiocccentry_bugs)". -

    -

    As part of its algorithm, `txzchk(1)` will run `fnamchk(1)` on the _tarball_ to verify that the _filename_ is valid. See the FAQ on "[fnamchk](../faq.html#fnamchk)" and the [fnamchk section](#fnamchk) below for more details on this tool. -

    -

    It is beyond the scope of this document to discuss the many tests that `txzchk(1)` performs; if you wish to know, we refer you to the [source code](https://github.com/ioccc-src/mkiocccentry/blob/master/txzchk.c) or the man page. You might just find a fun option if you do either of these! -

    -

    Of course, as `txzchk` does not extract the tarball, it is possible that if you manually package your submission tarball and/or find and exploit a missing check, you could still be violating [Rule 17](rules.html#rule17). -

    ## Including optional and extra files

    -The maximum total number of files that may be submitted has changed to **39** files. -However, of those files, **5** are mandatory (`prog.c`, `Makefile`, `remarks.md` and -the two JSON files generated by `mkiocccentry(1)`, `.info.json` and -`.auth.json`). +The maximum total number of _extra files_ that may be submitted is 31.

    -Additionally, three of the files, if included, **MUST** be -specific file(name)s **AND** in the top level directory, or they will be counted as -an extra file, not an optional 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_.

    -In particular, any file that is not `prog.c`, `Makefile`, `remarks.md`, -`try.sh`, `prog.alt.c` or `try.alt.sh` will be counted as an extra file, and if -`try.sh`, `prog.alt.c` or `try.alt.sh` are not in the top level submission -directory they will also be counted as an extra file. The `.info.json` and -`.auth.json` files are not counted as extra files but are required. +Of course any dot file that is not `.auth.json` and `.info.json` will result in +a violation of [Rule 17](rules.html#rule17), regardless of its depth.

    -

    -In other words, the actual amount of **EXTRA** files is **31**. -

    - -

    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. For more details on the optional files, see the +abuse of rules. + +

    +For information on the `try` script files see the FAQ on the "[try.sh script system](../faq.html#try_script)" -and the +and for more details on alt code (including the `try.alt.sh` script) see the FAQ on "[alt code](../faq.html#alt_code)".

    -If you **REALLY MUST** include more files than the limit allows, then you may do so by including as an extra -file, a tarball. This does **NOT** have to pass `txzchk(1)` tests; only the -submission tarball must pass the `txzchk(1)` tests. +If you really **MUST** include more files than the limit allows, then you may do +so by including as an extra file, a tarball. This does **NOT** have to pass +`txzchk(1)` tests; only the submission tarball must pass the `txzchk(1)` tests.

    +You **MUST** justify including extra files beyond the limit, should you do so. +Even so this does not mean it will be considered valid. +

    + +

    +If you use a tarball for a depth beyond the maximum, you **MUST** justify this +as well. Even so this does not mean it will be considered valid. +

    + If you **DO** include a tarball, and the build process or the program extracts -said tarball(s), the make `clobber` rule **MUST** remove the extracted files. Even so, if you -include a tarball to get past the limit on the number of files, you **MUST** -justify this in your `remarks.md` file. -

    +said tarball(s), the make `clobber` rule **MUST** remove the extracted files. -

    **IMPORTANT REMINDER**: make **SURE** your tarball does **NOT** reveal who you are! The `mkiocccentry(1)` tool creates a v7 format tarball to prevent this. You can do the same like: -

    ``` tar --format=v7 -cJf foo.txz directory ``` -

    -See [Rule 17](rules.html#rule17) and in particular the part about the [maximum -number of files](../faq.html#max-files). If you do not follow these points, you -are at a great risk of violating [Rule 17](rules.html#rule17)! -

    +See [Rule 17](rules.html#rule17) and also the +FAQ on "[maximum number of files](../faq.html#max-files)". + +If you do not follow these points, you +are at a great risk of violating [Rule 17](rules.html#rule17)! -

    **NOTE**: if you want to include a test-suite that requires a lot of files, please suggest this in your `remarks.md` and if your submission wins it can -be done. In other words you should not use a tarball for a test-suite unless you +be done. In other words you should NOT use a tarball for a test-suite unless you have a very good reason for this (and if you do, make **SURE** you specify why in your `remarks.md` file). -

    - -

    See also the FAQ on "[txzchk](../faq.html#txzchk)". -

    - Jump to: [top](#) @@ -883,21 +747,16 @@ Jump to: [top](#) ## `fnamchk(1)` -

    As an important part of its algorithm, [txzchk(1)](#txzchk) directly executes `fnamchk(1)`. If the filename is invalid (or the filename does not match the directory name of the tarball) then it is an **error** and you risk violating [Rule 17](rules.html#rule17). Nevertheless, you can run the tool manually, should you wish to. -

    -

    For more information on `fnamchk` and how to manually validate your submission tarball filename, see the FAQ on "[fnamchk](../faq.html#fnamchk)". -

    -

    It is extremely unlikely that `fnamchk(1)` reporting an invalid filename is a bug in `fnamchk(1)` and as such, ignoring such an issue risks violating [Rule 17](rules.html#rule17) which is a big risk. Of course, using `mkiocccentry(1)` @@ -907,38 +766,30 @@ you should [report it as a bug at the mkiocccentry issues page](https://github.com/ioccc-src/mkiocccentry/issues/new?assignees=&labels=bug&projects=&template=bug_report.yml&title=%5BBug%5D+%3Ctitle%3E). See the FAQ on "[reporting mkiocccentry bugs](../faq.html#mkiocccentry_bugs)". -

    -

    As you can see, the use of `mkiocccentry(1)` is **HIGHLY RECOMMENDED**, and at the risk of stating the obvious, you run **A VERY BIG RISK** of having your submission rejected if you package your own tarball, and there are **ANY -problems**. For instance, if `chkentry(1)` found a problem in your `.info.json` +problems**. For instance, if `chksubmit(1)` found a problem in your `.info.json` file, the `mkiocccentry(1)` tool would not package it. But if you were to package it manually, you would be violating [Rule 17](rules.html#rule17). But even if everything checks out OK you should **NOT** assume that everything **IS** OK. -

    -
    -# Problems and/or bugs in tools +# Problems and/or bugs in the mkiocccentry toolkit
    -

    Although the tools have been tested extensively, it is nonetheless possible for bugs to exist in the code, as all programmers know. In this case, **please** ask for help or report what you think is a bug via the [bug report issues page in the mkiocccentry repo](https://github.com/ioccc-src/mkiocccentry/issues/new?assignees=&labels=bug&projects=&template=bug_report.yml&title=%5BBug%5D+%3Ctitle%3E). -

    -

    Of course, it is also possible for `mkiocccentry(1)`, or one or more of the tools it executes (or another tool executes), to fail, but **NOT** because of a bug. An example problem is if there is not enough memory available or if some other library or syscall fails. Nonetheless it might be worth reporting as a bug; it is a judgement call: if it's a bug it'll be addressed and if it's not that's OK too! -

    @@ -947,35 +798,29 @@ that's OK too!
    -

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

    +This helps us fit the Makefile into a winning entry, should your submission win. +

    + 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)`. -

    @@ -983,45 +828,37 @@ and/or `gcc(1)`.
    -

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

    +You really should **NOT** redefine `CC` because doing so makes it less portable. <-- **Hint!** +

    + 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! -

    @@ -1030,11 +867,8 @@ in truth the `clang` compiler, as `/usr/bin/gcc --version` will show!
    -

    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 @@ -1052,11 +886,9 @@ by modifying the `CSTD` Makefile variable. For example, to use `c99` instead: -

    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 @@ -1068,27 +900,22 @@ For example, to compile without optimization, and to include debug symbols: -

    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)". @@ -1096,61 +923,45 @@ 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 @@ -1159,7 +970,6 @@ See also the FAQ on "[forced warnings](../faq.html#forced_warnings)" and the FAQ on "[-Weverything](../faq.html#weverything)". -

    ## Disabling warnings @@ -1171,7 +981,6 @@ 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**" @@ -1179,15 +988,12 @@ 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 @@ -1201,56 +1007,27 @@ 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 @@ -1261,73 +1038,59 @@ If you need to include a file (as in `#include`) on the command line, use the ## 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. -

    -

    While people are free to manage their submission under `git(1)` or even use a GitHub repo, dot-files and dot-directories such as `.git` are not allowed in a submission. -

    -

    The `mkiocccentry(1)` tool will ignore dot-files and dot-directories (such as `.vimrc`, `.bashrc`, `.git` and `.github`) and not put them in the submission's compressed tarball. So while you may use such files and directories to help develop your submission, they won't be included when you run the `mkiocccentry(1)` tool. -

    -

    Even if you did manage to get dot files or dot directories in the tarball somehow, `txzchk(1)` will flag it as an error. When the judges run `txzchk(1)` on the uploaded submission compressed tarball, if anything is wrong, for instance if you "sneak in" any dot files or dot directories, the submission **WILL BE REJECTED** for violating [Rule 17](rules.html#rule17)! -

    -

    You may use whatever tools you need to develop your submission, including the use of `git(1)` or `gh(1)`, just be sure that your submission code and your submission Makefile don't depend on such tools. -

    -

    Of course if you do use GitHub to work on your submission, you might want to make the repo private so you don't reveal who you are. :-) + +

    +In other words, make **SURE** you keep anonymous who submitted the code!

    -If this is not clear, please do **NOT** use these tools to help with the +Please do **NOT** use these tools to help with the `clobber` rule! For instance, do **NOT** use `git clean`! Not only does this depend on the user having `git(1)` but it also does not account for the submission tarballs. Even worse is when someone does have it in a `git(1)` repo @@ -1335,9 +1098,7 @@ it will remove files that are not under `git(1)` control! Instead, see the `clobber` rule in the example Makefile to see how to manage this.

    -

    In other words, for `make clobber`, do something like: -

    ``` @@ -1353,17 +1114,13 @@ and **NOT** something like this: -git clean -f # WRONG !!! ``` -

    And do **NOT** use `git` for any other `Makefile` rule either. -

    -

    **NOTE**: `mkiocccentry(1)` will directly run `make clobber` in the submission directory. And although it is not an error if this fails, if it fails because the Makefile does not have a clobber rule, it will be flagged by `mkiocccentry(1)` (you may ignore this but it does put you at a risk of violating the rules). -

    Jump to: [top](#) @@ -1375,32 +1132,24 @@ Jump to: [top](#) -

    We **VERY MUCH LIKE** submissions that use an edited variant of the example Makefile, as described and linked to in the [Makefile section](#makefile), renamed as `Makefile` of course. This makes it easier for the [IOCCC judges](../judges.html) to test your submission. And if your submissions wins, it makes it easier to integrate it into the [Official IOCCC winner website](https://www.ioccc.org/index.html). -

    -

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

    -

    It is **VERY MUCH** appreciated if your remarks 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.sh` example script (and if you have alternate code, the same applies with the `try.alt.sh` script): -

    - [view example try.sh](%%REPO_URL%%/next/try.sh) - download example try.sh @@ -1408,17 +1157,29 @@ the same applies with the `try.alt.sh` script): - [view example try.alt.sh](%%REPO_URL%%/next/try.alt.sh) - download example try.alt.sh -

    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](../faq.html#try_scripts)". + +

    +Even if it only has one invocation we still **LIKE** the try scripts.

    -You might wish to add `./try.sh` to the `try` rule in the Makefile you submit. -If you have alternate code, then you can use the `try.alt` rule as well. +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.alt` rule in +the Makefile. +

    + +

    +If you don't have a prog.alt.c, then **PLEASE** remove the `try.alt` rule as +well.

    Doing masses of `#define`s to obscure the source has become 'old'. We @@ -1433,10 +1194,8 @@ as a program that is more well rounded in confusion. #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: @@ -1445,22 +1204,16 @@ When declaring local or global variables, you should declare the type: this_is_not; /* <-- Try to avoid implicit type declarations */ ``` -

    We tend to **like _less_** a submission that requires either `gcc` **OR** `clang`. **We _prefer_ submissions** that can compile -under **BOTH** `gcc` **AND** `clang`. -

    +under **BOTH** `gcc` **AND** `clang`. **Hint!** -

    We **RECOMMEND** that the compiler flags you use in your submission's `Makefile` are supported by **BOTH** `gcc` **AND** `clang`. -

    -

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

    One side effect of the above is that you cannot assume the use of nested functions such as: @@ -1479,9 +1232,7 @@ 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`. -

    We prefer programs that do not require a fish license: crayons and cat detector vans not withstanding. @@ -1500,19 +1251,18 @@ 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. -

    -

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

    -

    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.md` file. + +

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

    On 28 January 2007, the Judges rescinded the requirement that the @@ -1531,20 +1281,16 @@ 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. -

    While those who are used to temperatures found on [dwarf planets](https://science.nasa.gov/dwarf-planets/) (**yes Virginia, dwarf planets _ARE_ planets!**), such as [Pluto](https://science.nasa.gov/dwarf-planets/pluto/), 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. -

    -

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

    We tend to **DISLIKE** programs that: @@ -1553,23 +1299,20 @@ We tend to **DISLIKE** programs that: sockets/streams specific code is likely not to be) * dump core or have compiler warnings (it is OK only if you warn us in your `remarks.md` file) -*

    won't compile or run in a [Single UNIX +* won't compile or run in a [Single UNIX Specification](https://en.wikipedia.org/wiki/Single_UNIX_Specification) -environment

    -*

    depend on a utility or application not normally found +environment +* depend on a utility or application not normally found in systems that conform to the [Single UNIX -Specification](https://en.wikipedia.org/wiki/Single_UNIX_Specification)

    -* abuse the build file to get around the size limit
    -*

    obfuscate by use of ANSI trigraphs

    -*

    obfuscate by use of digraphs

    -*

    are larger than they need to be

    -*

    have more lines than they need to have

    -*

    are "blob-ier" (just a pile of unformatted C code) -than they need to be

    -*

    are rather similar to **[previous -winners](../years.html)** :-(

    -*

    are **identical** to **[previous -losers](https://en.wikipedia.org/wiki/Null_device)** :-)

    +Specification](https://en.wikipedia.org/wiki/Single_UNIX_Specification) +* abuse the build file to get around the size limit +* obfuscate by use of ANSI trigraphs +* obfuscate by use of digraphs +* are larger than they need to be +* have more lines than they need to have +* are "blob-ier" (just a pile of unformatted C code) than they need to be +* are rather similar to **[previous winners](../years.html)** :-( +* are **identical** to **[previous losers](https://en.wikipedia.org/wiki/Null_device)** :-) * that mandate the exclusive use of a specific Integrated Development Environment (IDE) In order to encourage submission portability, we **DISLIKE** submissions that @@ -1577,12 +1320,10 @@ 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. -

    The program must compile and link cleanly in a [Single UNIX Specification](https://en.wikipedia.org/wiki/Single_UNIX_Specification) environment. Therefore do not assume the system has a [windows.h](https://en.wikipedia.org/wiki/Windows.h) include file: -

    ``` @@ -1608,32 +1349,24 @@ source under the size limit. Your source code, post-pre-processing, should not exceed the size of [Microsoft Windows](https://en.wikipedia.org/wiki/Microsoft_Windows). :-) -

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

    -

    The [IOCCC judges](../judges.html), 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 on [Earth](https://science.nasa.gov/earth/). :-) -

    -

    You should try to restrict commands used in the build file to commands found in [Single UNIX Specification](https://en.wikipedia.org/wiki/Single_UNIX_Specification) environments and systems that conform to the [Single UNIX Specification](https://en.wikipedia.org/wiki/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, etc.). @@ -1677,10 +1410,12 @@ Please try to be much more creative. We really **DISLIKE** submissions that make blatant use of including large data files to get around the source code size limit. +

    We do not recommend submitting [systemd](https://systemd.io) source code to the IOCCC, if nothing else because that code is likely to exceed [the source code size limit](rules.html#rule2). This isn't to say that another highly compact and obfuscated -replacement of `init` would not be an interesting submission. +replacement of `init(8)` would not be an interesting submission. +

    Did we remember to indicate that programs that blatantly use some complex state machine to do something simple, are boring? @@ -1688,7 +1423,6 @@ We think we did. :-) > All generalizations are false, including this one. -- **Mark Twain** -

    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 @@ -1696,7 +1430,6 @@ 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 the [IOCCC rules](rules.html) for details (in particular, [Rule 9](rules.html#rule9)). -

    We suggest that you avoid trying for the '**smallest self-replicating**' source. The smallest, a [zero byte entry](../1994/smr/index.html), won in @@ -1713,11 +1446,9 @@ is **NOT** 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 [Makefile section](#makefile)), do not assume this sort of code will work: -

    ``` char *T = "So many primes, so little time!"; @@ -1725,22 +1456,16 @@ sort of code will work: 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 */ ``` -

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

    X client submissions should be as portable as possible. Submissions that adapt to a wide collection of environments will be favored. For @@ -1755,27 +1480,21 @@ 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"](../faq.html#Xorg_deprecated)" 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. -

    This could be the only _guideline_ that contains the word [fizzbin](https://en.wikipedia.org/wiki/List_of_games_in_Star_Trek#Fizzbin). -

    However, do you know how to play [fizzbin](https://en.wikipedia.org/wiki/List_of_games_in_Star_Trek#Fizzbin)? You do?!? (Except on Tuesday?) -

    -

    OK, there are actually 2 _guidelines_ that contain the word [fizzbin](https://en.wikipedia.org/wiki/List_of_games_in_Star_Trek#Fizzbin), unless you count this one, in which case there are 3. :-) -

    We **DISLIKE** submissions that use proprietary toolkits such as the `M*tif`, `Xv*ew`, or `OpenL*ok` toolkits, since not everyone has them. Use an @@ -1783,33 +1502,23 @@ open source toolkit that is widely and freely available instead. **NOTE**: The previous _guideline_ in this spot has been replaced by this _guideline_: -

    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. They should also not depend on any particular window manager. -

    -

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

    -

    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](https://en.wikipedia.org/wiki/Single_UNIX_Specification). -

    -

    You are **well advised** to submit code that conforms to the [Single UNIX Specification Version 4](https://unix.org/version4/overview.html). -

    -

    To quote the [IOCCC judges](../judges.html): -

    > You very well might not be completely prohibited from failing to not partly misunderstand this particular _guideline_, but of course, we could not possibly @@ -1836,25 +1545,19 @@ 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. -

    You are better off explaining what your submission does in your `remarks.md` file section rather than leaving it obscure for the [IOCCC judges](../judges.html) as we might miss something and/or be too tired to notice. -

    -

    Please avoid this specific individual _guideline_, if it at all possible. -

    -

    We freely admit that interesting, creative or humorous comments in your `remarks.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 your `remarks.md` content during the judging process, so it is worth your while to write a remarkable `remarks.md` file. -

    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 @@ -1867,16 +1570,17 @@ One should restrict libcurses to portable features found on BSD or Linux curses.

    -[Rule 13](rules.html#rule13) no longer discourages the use of UTF-8 -characters in C code. +If you do `#include ` make **CERTAIN** you link in curses (i.e. +`-lcurses`) and not ncurses (i.e. `-lncurses`).

    -

    +[Rule 13](rules.html#rule13) no longer discourages the use of UTF-8 +characters in C code. + 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 format their submission using a "normal" formatting style @@ -1891,11 +1595,9 @@ about why you think your submission is obfuscated. On the other hand, 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 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**. -

    We believe that Mark Twain's quote: @@ -1903,30 +1605,25 @@ We believe that Mark Twain's quote: ... is a good motto for those writing code for the IOCCC. -

    The IOCCC size tool source is not an original work, unless you are [Anthony C Howe](../authors.html#Anthony_C_Howe), in which case it is original! :-) Submitting source code that uses the contents of [iocccsize.c](https://github.com/ioccc-src/mkiocccentry/blob/master/iocccsize.c), _unless_ you are [Anthony C Howe](../authors.html#Anthony_C_Howe), might run the risk of violating [Rule 7](rules.html#rule7). -

    -

    The IOCCC submission tarball validator source is not an original work, unless you are [Cody Boone Ferguson](../authors.html#Cody_Boone_Ferguson), in which case it is original! :-) Submitting source code that uses the contents of [txzchk.c](https://github.com/ioccc-src/mkiocccentry/blob/master/txzchk.c), _unless_ you are [Cody Boone Ferguson](../authors.html#Cody_Boone_Ferguson), might run the risk of violating [Rule 7](rules.html#rule7). -

    -

    In addition to the above tools, none of the [mkiocccentry tools](https://github.com/ioccc-src/mkiocccentry), _including, **but not limited**_ to [mkiocccentry](https://github.com/ioccc-src/mkiocccentry/blob/master/mkiocccentry.c), -[chkentry](https://github.com/ioccc-src/mkiocccentry/blob/master/chkentry.c), +[chksubmit](https://github.com/ioccc-src/mkiocccentry/blob/master/chksubmit.c), [chksubmit](https://github.com/ioccc-src/mkiocccentry/blob/master/chksubmit.c), [fnamchk](https://github.com/ioccc-src/mkiocccentry/blob/master/test_ioccc/fnamchk.c) and @@ -1945,9 +1642,7 @@ library, _unless_ you are [Cody Boone Ferguson](../authors.html#Cody_Boone_Ferguson) or [Landon Curt Noll](http://www.isthe.com/chongo/index.html), might run the risk of violating [Rule 7](rules.html#rule7). -

    -

    And unless you are [Landon Curt Noll](https://en.wikipedia.org/wiki/Landon_Curt_Noll), the code in [dbg](https://github.com/ioccc-src/mkiocccentry/tree/master/dbg) and @@ -1955,9 +1650,7 @@ the code in not original works. Submitting source code that uses the contents of those libraries, _unless_ you [Landon Curt Noll](https://en.wikipedia.org/wiki/Landon_Curt_Noll), might run the risk of violating [Rule 7](rules.html#rule7). -

    -

    [Rule 7](rules.html#rule7) does not prohibit you from writing your own obfuscated versions of these tools, unless of course you are [Landon Curt Noll](http://www.isthe.com/chongo/index.html), in which case you _probably_ @@ -1965,9 +1658,7 @@ won't win since [IOCCC judges](../judges.html) should not enter the IOCCC! :-) However, **_if_** you do write your own version, you **_might_** wish to make it do something **_more_ interesting** than simply implementing the [IOCCC](../index.html) tools' algorithms. -

    -

    Even so, we do not recommend you try and submit a JSON parser due to the fact it will likely exceed [the source code size limit](rules.html#rule2) and because you likely can't beat [flex](https://github.com/westes/flex) and @@ -1980,41 +1671,32 @@ because of the [source code size limit](rules.html#rule2) or because it is not as obfuscated as the [flex](https://github.com/westes/flex) and [bison](https://www.gnu.org/software/bison/) generated code of [jparse](https://github.com/ioccc-src/mkiocccentry/blob/master/jparse). -

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

    If the [IOCCC judges](../judges.html) are feeling ornery we 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 :-) -

    -

    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 [Makefile section](#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 **NOT** support 32-bit! -

    -

    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 up `2305567963945518424753102147331756070`. Attempting to factor larger values will produce unpredictable results. @@ -2031,9 +1713,7 @@ However the [IOCCC judges](../judges.html) might try to also factor 0, so you wa `2305567963945518424753102147331756070`. 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 and `2305567963945518424753102147331756070`. Attempting to factor anything else @@ -2060,48 +1740,34 @@ and state: 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 of `2305567963945518424753102147331756070` as it is not of prime importance: or is it? :-) -

    -

    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 [IOCCC markdown guidelines](../markdown.html) 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 19](rules.html#rule19) and our FAQ on "[markdown](../faq.html#markdown)". -

    -

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

    Try to be even more creative! @@ -2132,7 +1798,6 @@ 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. -

    If you intend to abuse the [IOCCC rules](rules.html), indicate so in your `remarks.md` file. You **MUST** try to justify why you consider your rule abuse to be allowed under the @@ -2141,24 +1806,18 @@ your submission is valid. Humor and/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 do bypass the `mkiocccentry(1)` warnings about [Rule 2a](rules.html#rule2a) and/or about [Rule 2b](rules.html#rule2b) or any other rule and submit a submission anyway, you **MUST** try to justify why the IOCCC [IOCCC judges](../judges.html) 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](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 @@ -2169,9 +1828,7 @@ 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 truck through the holes" in the [IOCCC rules](rules.html) and [IOCCC guidelines](guidelines.html). -

    -

    At the risk of stating the obvious, this contest is a parody of the software development process. The [IOCCC rules](rules.html) and [IOCCC guidelines](guidelines.html) are only part of the overall contest. Even so, one might think the @@ -2182,7 +1839,6 @@ sometimes conflicting 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. -

    Jump to: [top](#) @@ -2194,13 +1850,11 @@ Jump to: [top](#) Submissions are judged by Leonid A. Broukhis and Landon Curt Noll. -

    Each submission submitted is given a random string and subdirectory. The submission files including, but not limited to `prog.c`, `Makefile`, `remarks.md`, `.info.json`, `.auth.json` as well as any data files that you submit, are all placed under their own directory and stored and judged from this directory. -

    Any information about the authors is not read by the [IOCCC judges](../judges.html) until the judging process is complete, and then only from entries that have @@ -2211,11 +1865,9 @@ The above process helps keep us biased for/against any one particular individual. Therefore you **MUST** refrain from putting any information that reveals your identity in your submission. -

    Now some people point out that coding and/or writing style might reveal the information about the authors. However we consider this to be simply circumstantial and outside the scope of the above paragraph. -

    Some people, in the past, have attempted to obfuscate their identity by including comments of famous Internet personalities such as [Peter @@ -2250,16 +1902,12 @@ attempts to send non-winners into oblivion. We remove all non-winning files, and shred all related printouts. By tradition, we do not even reveal the number of submissions that we receive. -

    During the judging process, a process that spans multiple sessions over a few weeks, we post general updates from our [Mastodon account](https://fosstodon.org/@ioccc). -

    -

    **Make sure you reload the feed** every so often **because unless you are mentioned you will NOT get a push notification!** -

    Jump to: [top](#) @@ -2286,8 +1934,8 @@ Jump to: [top](#) A reading consists of a number of actions: -*

    Reading `prog.c`, the C source and reviewing the `remarks.md` information

    -*

    Briefly looking at any supplied data files

    +* Reading `prog.c`, the C source and reviewing the `remarks.md` information +* Briefly looking at any supplied data files * Passing the source thru the C pre-processor skipping over any `#include`d files * Performing a number of C beautify/cleanup edits on the source * Passing the beautified source thru the C pre-processor skipping over any `#include`d files @@ -2298,14 +1946,10 @@ A reading consists of a number of actions: In later rounds, other actions are performed including performing miscellaneous tests on the source and binary. -

    This is the very **guideline** that goes, **BING!** -

    -

    Okay, technically that was the _second_ **guideline** that goes **BING**, and this is the third. :-) -

    Until we reduce the stack of submissions down to about 25 submissions, submissions are judged on an individual basis. A submission is set aside because it @@ -2324,9 +1968,8 @@ we receive. A typical category list might be: * **best game that is obfuscated** * **most creatively obfuscated program** * **most deceptive C code** (code with deceptive comments and source code) -*

    **best X program** (see [OUR LIKES AND DISLIKES](#likes) -and the -FAQ on "[Xorg being deprecated](../faq.html#Xorg_deprecated)")

    +* **best X program** (see [OUR LIKES AND DISLIKES](#likes) and the FAQ on "[Xorg +being deprecated](../faq.html#Xorg_deprecated)") * **best abuse of ISO C or ANSI C standard** (see above about compilers) * **best abuse of the C preprocessor** * **worst/best abuse of the rules** (or some variation) @@ -2351,14 +1994,16 @@ worthwhile to resubmit an improved version of a submission that failed to win in a previous year, the next year. This assumes, of course, that the submission is worth improving in the first place! -

    Over the years, more than one [IOCCC judge](../judges.html) has been known to **bribe** another [IOCCC judge](../judges.html) into voting for a winning submissions by offering a bit of high quality chocolate, or other fun item. -

    +Over the years some judges have submitted code that had to be rejected once it +was discovered to be a judge. +

    + One **should NOT** attempt to **bribe** an [IOCCC judge](../judges.html), **unless you are an [IOCCC judge](../judges.html)**, because **bribing** an [IOCCC judge](../judges.html) by a non-judge @@ -2366,9 +2011,7 @@ has been shown to **NOT** be effective when the **person _attempting_ the _bribe_ is made known** to the [IOCCC judges](../judges.html) (i.e., they are not anonymous) AND/OR the **bribe** is otherwise associated with a submission to the [IOCCC](../index.html). -

    -

    With the previous guideline in mind: **anonymous** gifts for the [IOCCC judges](../judges.html) that are **NOT ASSOCIATED WITH** a submission to the [IOCCC](../index.html) may be sent to the @@ -2378,12 +2021,9 @@ It has been shown that receiving **anonymous** gifts provides the [IOCCC judges](../judges.html) with a nice [dopamine](https://en.wikipedia.org/wiki/Dopamine) boost, and happy [IOCCC judges](../judges.html) help make the [IOCCC](../index.html) better for everyone. :-) -

    -

    See the FAQ on "[supporting the IOCCC](../faq.html#support)". -

    More often than not, we select a small submission (usually one line) and a strange/creative layout submission. We sometimes also select a @@ -2391,9 +2031,7 @@ submission that abuses the [IOCCC guidelines](guidelines.html) in an interesting or that stretches the contest [rules](rules.html) that while legal, it nevertheless goes against the **intent** of the [rules](rules.html). -

    Nevertheless, see [Rule 12](rules.html#rule12). -

    In the end, we traditionally pick one submission as '**best**'. Sometimes such a submission simply far exceeds any of the other submissions. More often, the @@ -2411,17 +2049,13 @@ Jump to: [top](#) # ANNOUNCEMENT OF WINNERS: -

    The [IOCCC judges](../judges.html) will toot initial announcement of who won, the name of their award, and a very brief description (award title) of the winning entry from the [@IOCCC Mastodon account](https://fosstodon.org/@ioccc). -

    -

    We recommend that you follow us on mastodon but **please make sure to refresh the feed** every so often (if not more often) because unless you are mentioned or someone boosts your post you will not get a push notification. -

    Jump to: [top](#) @@ -2431,35 +2065,23 @@ Jump to: [top](#) ## How the new IOCCC winners will be announced -

    The [current status of the IOCCC](../status.html) will change from **[judging](../faq.html#judging)** to **[closed](../faq.html#closed)** . -

    -

    The **contest_status** in the [status.json](../status.json) file will change from **judging** to **closed** as well. -

    -

    When the above happens, the winning entries have been selected by the [IOCCC judges](../judges.html). -

    -

    The [IOCCC judges](../judges.html) will begin to prepare to release the source code of the new IOCCC winners. -

    -

    The [IOCCC judges](../judges.html) will commit the winning source to the [IOCCC winner repo](https://github.com/ioccc-src/winner) which will update the [Official IOCCC website](https://www.ioccc.org/index.html). -

    -

    The [IOCCC news](../news.html) will also contain an announcement of the winners. -

    Jump to: [top](#) @@ -2484,10 +2106,8 @@ In addition a note is posted to the [IOCCC Mastodon account](https://fosstodon.o We will also post a notice to the IOCCC discord server.

    -

    Consider joining the IOCCC discord community via this link: [https://discord.gg/Wa42Qujwnw](https://discord.gg/Wa42Qujwnw) -

    Jump to: [top](#) @@ -2497,20 +2117,16 @@ Jump to: [top](#) ## Back to announcement of winners -

    It is pointless to ask the [IOCCC judges](../judges.html) how many submissions we receive. See [How many submissions do the judges receive for a given IOCCC?](../faq.html#how_many). -

    -

    Often, winning entries are published in selected magazines from around the world. Winners have appeared in books ('`The New Hacker's Dictionary`', '`Obfuscated C and Other Mysteries`', '`Pointers On C`', others) and on t-shirts (sometimes by the author(s) themselves). There have been multiple classes that have focused in part, on IOCCC winning entries. And more than one winner has been turned into a tattoo! -

    Last, but not least, [winners](../authors.html) receive international fame and flames! :-) @@ -2524,41 +2140,28 @@ Jump to: [top](#) -

    For questions or comments about the contest, see [Contacting the IOCCC](../contact.html). -

    -

    **Be SURE** to review the [IOCCC Rules and Guidelines](index.html) as they may (and **often do**) change from year to year. -

    -

    **PLEASE** be sure you have the current [IOCCC rules](rules.html) and [IOCCC guidelines](guidelines.html) prior to submitting to the contest. -

    See the [Official IOCCC website news](../news.html) for additional information. -

    For the updates and breaking IOCCC news, you are encouraged to follow the [IOCCC on Mastodon](https://fosstodon.org/@ioccc). See our FAQ on "[Mastodon](../faq.html#try_mastodon)" for more information. Please do note that unless you are mentioned by us you will **NOT** get a notification from the app _so you should refresh the page **even if you do follow us**_. -

    -

    Check out the [Official IOCCC winner website](https://www.ioccc.org/index.html) in general. -

    -

    Consider joining the IOCCC discord community via this link: [https://discord.gg/Wa42Qujwnw](https://discord.gg/Wa42Qujwnw) -

    -

    See the FAQs on "[obtaining, compiling, installing and using the mkiocccentry tools](../faq.html#mkiocccentry)" and the @@ -2567,7 +2170,6 @@ as that FAQ has important details on [how to register](../next/register.html) as well as [how to upload your submission](../next/submit.html) for the IOCCC. -

    diff --git a/next/rules.html b/next/rules.html index 10e9e28b6..a3c7fba3b 100644 --- a/next/rules.html +++ b/next/rules.html @@ -488,12 +488,10 @@ writing by contacting the judges.

    -These IOCCC rules are version 28.30 2025-03-03. -

    -

    -The markdown form of these rules is -available for download. +These IOCCC rules are version 28.31 2025-11-17.

    +

    The markdown form of these rules is +available for download.

    IMPORTANT: Be sure to read the IOCCC guidelines.

    Jump to: top

    @@ -545,16 +543,14 @@ This contest will enter the judgingIMPORTANT NOTE: Until the contest enters the open state, any or all of the above dates and times may change!

    -

    -See the +

    See the FAQ on “obtaining and compiling the mkiocccentry tools” and the FAQ on “how to enter the IOCCC” as that FAQ has important details on how to register as well as -how to upload your submission to the IOCCC. -

    +how to upload your submission to the IOCCC.

    Jump to: top

    IOCCC RULES

    @@ -563,192 +559,132 @@ as well as

    A warning about rule abuse

    -

    -WARNING: Abusing these rules comes with a fair amount of risk +

    WARNING: Abusing these rules comes with a fair amount of risk that your submission will be rejected. If you do plan to abuse the rules, then you MUST CLEARLY EXPLAIN THE RATIONALE in your remarks.md file, as to why you think your rule abuse should be allowed, and as to why you think your submission should not be rejected for a rule violation. Nevertheless, even if you do explain this in your remarks.md file -you submission may still be rejected. -

    -

    -If you use the most recently released official IOCCC submission packaging tool +you submission may still be rejected.

    +

    If you use the most recently released official IOCCC submission packaging tool (hereby referred to as mkiocccentry(1)), which we STRONGLY recommend you do, then the mkiocccentry(1) tool will warn you if there appears to be a violation in certain rules (not all can be detected). The mkiocccentry(1) -tool also runs chkentry(1) and txzchk(1), the latter of which runs +tool also runs chksubmit(1) and txzchk(1), the latter of which runs fnamchk(1). Overriding problems detected by any of these tools comes with a -fair amount of risk that your submission will be rejected. -

    -

    -If you do override a rule violation warning from the mkiocccentry(1) or +fair amount of risk that your submission will be rejected.

    +

    If you do override a rule violation warning from the mkiocccentry(1) or another related IOCCC tool, or otherwise plan to abuse the rules, then you MUST CLEARLY EXPLAIN THE RATIONALE of why you are attempting to abuse the rules in your remarks.md file. Even if you do explain this in your -remarks.md file your submission may still be rejected. -

    -

    -HINT: If you do submit such a rule abusing / rule violating +remarks.md file your submission may still be rejected.

    +

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

    -

    -IMPORTANT: if you do submit such an alternate non-rule abusing version, +in case your rule abuse excuse is rejected.

    +

    IMPORTANT: if you do submit such an alternate non-rule abusing version, PLEASE indicate that in your remarks.md file of your non-rule abusing version so that the IOCCC judges do not think you uploaded a -duplicate into a wrong slot by mistake. -

    -

    -Uploading a tarball not formed by mkiocccentry(1) puts you at a very big risk of +duplicate into a wrong slot by mistake.

    +

    Uploading a tarball not formed by mkiocccentry(1) puts you at a very big risk of violating Rule 17, especially as mkiocccentry(1) does a great number of things that are required, and it also runs many checks, and if any of those checks fail, you are at a very great risk of having your submission -rejected for violating Rule 17. -

    -

    -See also Rule 12. -

    +rejected for violating Rule 17.

    +

    See also Rule 12.

    Jump to: top

    Rule 0

    -

    -Just as C starts at 0, so the IOCCC starts at Rule 0. :-) -

    -

    -The “Important IOCCC dates” section above is part of this rule. -

    +

    Just as C starts at 0, so the IOCCC starts at Rule 0. :-)

    +

    The “Important IOCCC dates” section above is part of this rule.

    Jump to: top

    Rule 1

    -

    -Your submission must be a C program. -

    -

    -You see, the contest is not called the International Obfuscated JSON Contest +

    Your submission must be a C program.

    +

    You see, the contest is not called the International Obfuscated JSON Contest (IOJSONC), even if the so-called JSON spec might be called obfuscated -by some people. :-) -

    +by some people. :-)

    Jump to: top

    Rule 2

    Rule 2 requires that your submission satisfy BOTH Rule 2a AND Rule 2b.

    -

    -You may check your code with respect to Rule 2a and Rule +

    You may check your code with respect to Rule 2a and Rule 2b prior to submitting your code by giving the filename -as a command like argument to the iocccsize(1) tool. For example: -

    +as a command like argument to the iocccsize(1) tool. For example:

        iocccsize prog.c
    -

    -The source to iocccsize(1) may be found in the -mkiocccentry repo. -

    -

    -See also the +

    The source to iocccsize(1) may be found in the +mkiocccentry repo.

    +

    See also the FAQ on “how to further test your submission” -for more more thorough testing, including Rule 2. -

    -

    -See also Rule 2a, Rule 2b, and Rule 17. -

    +for more more thorough testing, including Rule 2.

    +

    See also Rule 2a, Rule 2b, and Rule 17.

    Jump to: top

    Rule 2a

    -The size of your program source should NOT exceed 4993 bytes. +The size of your program source MUST NOT exceed 4993 bytes.

    Jump to: top

    Rule 2b

    -

    -When the filename of your program source is given as a command line argument to +

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

    -

    -See also Rule 17. -

    +iocccsize(1)), the value printed MUST NOT exceed 2503.

    +

    See also Rule 17.

    Jump to: top

    Rule 3

    -

    -You must register in order to submit your entry to the IOCCC. +

    You must register in order to submit your entry to the IOCCC. You may register while the contest is either -pending or open. -

    -

    -When the contest is open, the submit server +pending or open.

    +

    When the contest is open, the submit server will email you your submit server Username and Initial password. Please be patient as it may take some time, -perhaps as much as a few days, for your registration to be processed and for that email to be sent. -

    -

    -Those who register while the contest status is pending +perhaps as much as a few days, for your registration to be processed and for that email to be sent.

    +

    Those who register while the contest status is pending will receive their email (containing their submit server Username and Initial password), later: usually a few days around the time when the contest status -becomes open. -

    -

    -Once that email with your Username and Initial password is sent, you -will have fortnight (14 days) to change your submit server initial password. -

    -

    -If you do not change your Initial password in time, you will have to +becomes open.

    +

    Once that email with your Username and Initial password is sent, you +will have fortnight (14 days) to change your submit server initial password.

    +

    If you do not change your Initial password in time, you will have to send email to the IOCCC judges -to ask for your password to be reset. -

    -

    -Because it takes time (maybe even a few days) to process your registration +to ask for your password to be reset.

    +

    Because it takes time (maybe even a few days) to process your registration and for the server to email you your initial login and password, you should MAKE SURE you give yourself enough time to register well before the contest closes. In other words, DO NOT WAIT UNTIL THE FINAL DAYS of the contest to register! The IOCCC judges are NOT responsible for delayed or lost email, or for those who wait -until the last minute to try to register! -

    -

    -See the +until the last minute to try to register!

    +

    See the FAQ on “how to register and submit to the IOCCC” for instructions on registering and participating in the IOCCC, as the process -may change from contest to contest. -

    -

    -See also Rule 8. -

    +may change from contest to contest.

    +

    See also Rule 8.

    Jump to: top

    Rule 4

    -

    -If your submission is selected as a winning entry, then your submission may be modified in order -to fit into the structure of the Official IOCCC winner website. -

    -

    -For example, your submission’s Makefile will be modified and your remarks.md -will become a README.md which will be used to generate an index.html file. -

    -

    -Your source code will be the file prog.c. The compiled binary +

    If your submission is selected as a winning entry, then your submission may be modified in order +to fit into the structure of the Official IOCCC winner website.

    +

    For example, your submission’s Makefile will be modified and your remarks.md +will become a README.md which will be used to generate an index.html file.

    +

    Your source code will be the file prog.c. The compiled binary will be called prog. If you submission requires different filenames, then modify your submission’s Makefile to COPY (NOT move!) the files -accordingly. -

    -

    -Of course your program may also do this, as long as it works, but you’re welcome -to use your Makefile as well. -

    -

    -See also Rule 5, Rule 18 and Rule 21. -

    +accordingly.

    +

    Of course your program may also do this, as long as it works, but you’re welcome +to use your Makefile as well.

    +

    See also Rule 5, Rule 18 and Rule 21.

    Jump to: top

    Rule 5

    @@ -758,64 +694,45 @@ part of your original submission including, but not limited to prog.cMakefile or any data files you submit.

    If you submission needs (or wishes :-) ) to modify such content, it MUST first copy the file to a new filename and then modify that copy.

    -

    -You may use your submission (program) to form a copy, or you can make use of -your Makefile to form that copy. -

    -

    -If you do make a copy of a submission file, PLEASE be sure that +

    You may use your submission (program) to form a copy, or you can make use of +your Makefile to form that copy.

    +

    If you do make a copy of a submission file, PLEASE be sure that the clobber rule of your Makefile removes that copy in order to -restore your submission to its original submission state. -

    +restore your submission to its original submission state.

    Jump to: top

    Rule 6

    -

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

    -

    -        while (!(ioccc(rule(you(are(number(6)))))) {
    +

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

    +

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

    +        }

    Jump to: top

    Rule 7

    -

    -The obfuscated C program must be your own original work. -

    -

    -You (the author(s)) MUST own the contents of your submission OR -you MUST have permission from the owner(s) to submit their content. -

    -

    -If you submit any content that is owned by others, you MUST +

    The obfuscated C program must be your own original work.

    +

    You (the author(s)) MUST own the contents of your submission OR +you MUST have permission from the owner(s) to submit their content.

    +

    If you submit any content that is owned by others, you MUST detail that ownership (i.e., who owns what) AND document the -permission you obtained from them, in your remarks.md file. -

    -

    -Please note that the tools in mkiocccentry +permission you obtained from them, in your remarks.md file.

    +

    Please note that the tools in mkiocccentry repo are NOT original works, -unless of course you’re the original authors, in which case they are original. :-) -

    -

    -Nevertheless tools such as those listed are NOT obfuscated. If submitted, they -would probably violate a number of rules. :-) -

    +unless of course you’re the original authors, in which case they are original. :-)

    +

    Nevertheless tools such as those listed are NOT obfuscated. If submitted, they +would probably violate a number of rules. :-)

    -

    -The IOCCC has a rich history of remarkable winning entries created by +

    The IOCCC has a rich history of remarkable winning entries created by authors who skillfully employed various techniques to develop their code. While it is NOT required, you are allowed to use tools to develop and test your submission. These tools may include, but are not limited @@ -823,77 +740,50 @@ to code generators, code analysis tools, static code analysis tools, runtime analysis tools, machine learning tools, natural language models, code copilot tools, so-called AI services, large language models (LLMs), etc. If you do make use of such tools or services, then we ENCOURAGE you to describe -what tools and how you used those tools, in your remarks.md file. -

    -

    -See also Rule 5, Rule 18 and Rule 21. -

    +what tools and how you used those tools    , in your remarks.md file.

    +

    See also Rule 5, Rule 18 and Rule 21.

    Jump to: top

    Rule 8

    -

    -Submissions may only be uploaded to the IOCCC submit server -while the contest is open. -

    -

    -If you have registered and received by email your submit +

    Submissions may only be uploaded to the IOCCC submit server +while the contest is open.

    +

    If you have registered and received by email your submit server Username and Initial password you may upload your submission to the submit server but -ONLY while the contest is open. -

    -

    -The submit server, in accordance with Rule +ONLY while the contest is open.

    +

    The submit server, in accordance with Rule 17, places a limit of 3999971 bytes on the size of your -upload. -

    -

    -Once the contest is in the judging state (or -closed state), you may NOT upload submissions. -

    -

    -While the contest is open or in the +upload.

    +

    Once the contest is in the judging state (or +closed state), you may NOT upload submissions.

    +

    While the contest is open or in the judging state, the IOCCC judges MAY (but are not required to) modify the slot comment of your submission to indicate that they have received it. If uploaded submission is malformed, the IOCCC judges MAY (but are not required to) modify the slot -comment accordingly. -

    -

    -You are STRONGLY advised to use the mkiocccentry(1) tool +comment accordingly.

    +

    You are STRONGLY advised to use the mkiocccentry(1) tool as found in the mkiocccentry repo -to form the file to upload to the submit server. -

    -

    -The submit server will become active when the +to form the file to upload to the submit server.

    +

    The submit server will become active when the contest is open. Until the contest status becomes open, the submit server may -be offline and/or unresponsive. -

    -

    -See the +be offline and/or unresponsive.

    +

    See the FAQs on “obtaining, compiling, installing and using the latest release of the mkiocccentry tools” -for more information about the mkiocccentry(1) tool. -

    -

    -See the “Important IOCCC dates” section above for when these contest states are scheduled. -

    -

    -See also Rule 3 and Rule 17. -

    +for more information about the mkiocccentry(1) tool.

    +

    See the “Important IOCCC dates” section above for when these contest states are scheduled.

    +

    See also Rule 3 and Rule 17.

    Jump to: top

    Rule 9

    -

    -Each PERSON may register ONLY ONE account and each account may submit up to -and including 10.000000 (ten in base 10) submissions PER contest. -

    +

    Each PERSON may register ONLY ONE account and each account may submit up to +and including 10.000000 (ten in base 10) submissions PER contest.

    Each submission must be submitted separately.

    -

    -If this seems unreasonable we suggest you wait until the next contest and in -the interim ponder this (modified or not) quote said by Bill Gates: -

    +

    If this seems unreasonable we suggest you wait until the next contest and in +the interim ponder this (modified or not) quote said by Bill Gates:

    640K submissions ought to be enough for anybody.

    – Bill Gates s/640K/10/ (allegedly :-) )

    @@ -914,14 +804,10 @@ DISCOURAGED. We do not guarantee these functions will behave as you expect on our test platforms. If your program needs special permissions you MUST document this fact, and explain why it is needed in your submission’s remarks.md file.

    -

    -Furthermore, if you need a supplementary program that you include, to have these +

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

    -

    -See also Rule 17. -

    +allowed in submissions and those bits will not be copied by mkiocccentry(1).

    +

    See also Rule 17.

    Jump to: top

    Rule 12

    @@ -930,163 +816,118 @@ See also Rule 17. the opinion of the judges, violates the rules WILL BE DISQUALIFIED. Submissions that attempt to abuse the rules MUST try to justify why their rule abuse is legal, in the remarks.md file.

    -

    -See also the warning about rule abuse. -

    +

    See also the warning about rule abuse.

    Jump to: top

    Rule 13

    -

    -7 out of 13 UTF-8 characters in C code agree that this rule number is lucky -enough to be a prime number. -

    -

    -Fun fact: the fear of the number 13 is called triskaidekaphobia. -

    +

    7 out of 13 UTF-8 characters in C code agree that this rule number is lucky +enough to be a prime number.

    +

    Fun fact: the fear of the number 13 is called triskaidekaphobia.

    Jump to: top

    Rule 14

    -

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

    -

    -Please do NOT put trailing control-M’s on prog.c, Makefile, or +

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

    +

    Please do NOT put trailing control-M’s on prog.c, Makefile, or remarks.md files but instead end lines with a trailing newline (i.e., -byte 012) character. -

    -

    -As we do NOT use DOS, please also be sure that the Makefile and -remarks.md files end in final newline (i.e., byte 012) character. -

    -

    -You are permitted, in order to try and squeeze your prog.c under +byte 012) character.

    +

    As we do NOT use DOS, please also be sure that the Makefile and +remarks.md files end in final newline (i.e., byte 012) character.

    +

    You are permitted, in order to try and squeeze your prog.c under a Rule 2a and/or Rule 2b limit, to NOT end your prog.c with a newline (i.e., byte 012) character. If you need to do this, PLEASE document that in your remarks.md file and if your compiler complains about this, document this too and update your -Makefile to account for this. -

    +Makefile to account for this.

    Jump to: top

    Rule 15

    -

    -In order to register for the IOCCC, you MUST have a valid email address. -

    -

    -The judges are NOT responsible for delays in email, so please plan -enough time accordingly. -

    -

    -See the +

    In order to register for the IOCCC, you MUST have a valid email address.

    +

    The judges are NOT responsible for delays in email, so please plan +enough time accordingly.

    +

    See the FAQ on “how to register” -for details. -

    +for details.

    Jump to: top

    Rule 16

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

    -

    -You are allowed to resubmit to a later contest, a submission that +

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

    -

    -Resubmitting an improved submission that did not become an +as this sometimes helps.

    +

    Resubmitting an improved submission that did not become an IOCCC winning entry is a time honored tradition of the IOCCC. There are some IOCCC winning entries that were submitted to multiple contests before they were improved enough to “climb over” (as the expression -goes) all the other submissions for a given contest. -

    +goes) all the other submissions for a given contest.

    Jump to: top

    Rule 17

    -

    -Your submission must be in the form of a xz compressed tarball that +

    Your submission must be in the form of a xz compressed tarball that the current released version of the mkiocccentry(1) tool would generate. The files, directories, and paths MUST conform to the limits imposed by mkiocccentry(1) including but NOT LIMITED to their names, count, -path length, directory tree depth and permissions. -

    -

    -Your xz compressed tarball must be larger than 0 bytes and no larger -than 3999971 bytes. -

    -

    -The sum of the byte lengths of all files, after the xz compressed tarball is untarred, -must NOT exceed 27651*1024 bytes. -

    -

    -Your xz compressed tarball submission file MUST pass the tests performed by -the current version of txzchk(1). -

    -

    -Your xz compressed tarball submission filename MUST pass the tests -performed by the current version of fnamchk(1). -

    -

    -When your xz compressed tarball submission file is untarred, the +path length, directory tree depth and permissions.

    +

    Your xz compressed tarball must be larger than 0 bytes and no larger +than 3999971 bytes.

    +

    The sum of the byte lengths of all files, after the xz compressed tarball is untarred, +must NOT exceed 27651*1024 bytes.

    +

    Your xz compressed tarball submission file MUST pass the tests performed by +the current version of txzchk(1).

    +

    Your xz compressed tarball submission filename MUST pass the tests +performed by the current version of fnamchk(1).

    +

    When your xz compressed tarball submission file is untarred, the resulting directory MUST pass the checks performed by the current version -of chkentry(1). -

    -

    -The resulting prog.c file MUST pass the Rule 2 size checks performed by the current -version of iocccsize(1). -

    -

    -The .auth.json and .info.json MUST be compatible with what the +of chksubmit(1).

    +

    The resulting prog.c file MUST pass the Rule 2 size checks performed by the current +version of iocccsize(1).

    +

    The .auth.json and .info.json MUST be compatible with what the current version of the mkiocccentry(1) tool would produce. They MUST -ALSO pass the tests performed by the current version of chkentry(1). -

    -

    -The required Makefile must NOT be empty. -

    -

    -The required remarks.md must NOT be empty. -

    -

    -You may NOT submit a tarball created by the -d or -s seed option of -mkiocccentry(1). -

    +ALSO pass the tests performed by the current version of chksubmit(1).

    +

    The required Makefile must NOT be empty.

    +

    The required remarks.md must NOT be empty.

    +

    You may NOT submit a tarball created by the -d or -s seed option of +mkiocccentry(1).

    The maximum number of files your submission tarball may contain, not counting -the optional files (prog.alt.c, try.sh, try.alt.sh) and the mandatory -files (prog.c, Makefile, remarks.md) is 31. +the free files (prog.c, remarks.md, Makefile, prog.alt.c, try.sh, +try.alt.sh and the two files generated by mkiocccentry, .info.json and +.auth.json) is 31. +

    +

    +The maximum number of directories your submission may have is 13 and the maximum +depth a path may have is 4. +

    +

    +The maximum filename length (a component of a path) is 38 which means the +maximum length total of a path is 60 characters.

    See the FAQ on “what extra files are and how to include more” as well as the guidelines on extra files for more details.

    TL;DR Rule 17 - Use mkiocccentry(1) to form your submission

    -

    -Let the current version of the mkiocccentry(1) tool form your xz -compressed tarball submission file. -

    +

    Let the current version of the mkiocccentry(1) tool form your xz +compressed tarball submission file.

    Warning

    -

    -Using command line flags or input prompts to override checks and +

    Using command line flags or input prompts to override checks and limits made by the above mentioned tools is NOT recommended and may result in your submission being rejected by the IOCCC -submit server and/or the IOCCC Judges. -

    -

    -See the +submit server and/or the IOCCC Judges.

    +

    See the FAQ on the “mkiocccentry toolkit -for how to obtain and use the above mentioned tools. -

    -

    -IMPORTANT: See the +for how to obtain and use the above mentioned tools.

    +

    IMPORTANT: See the FAQ on “Rule 17” -for very important details behind this rule. -

    +for very important details behind this rule.

    Jump to: top

    Rule 18

    @@ -1095,53 +936,37 @@ for very important details behind this rule.

    CC BY-SA 4.0 DEED Attribution-ShareAlike 4.0 International

    -

    -See also Rule 7. -

    +

    See also Rule 7.

    Jump to: top

    Rule 19

    -

    -The remarks.md file, a required non-empty file, must be written in -Markdown format. -

    -

    -We currently use pandoc(1) to automatically +

    The remarks.md file, a required non-empty file, must be written in +Markdown format.

    +

    We currently use pandoc(1) to automatically convert markdown to HTML. Please try to avoid submitting an HTML file translation to any markdown file. If you MUST submit such an HTML -translation, PLEASE mention this in your remarks.md file. -

    -

    -For any submission that wins the contest, we modify your remarks.md file and +translation, PLEASE mention this in your remarks.md file.

    +

    For any submission that wins the contest, we modify your remarks.md file and rename it as README.md and then use pandoc(1) to generate the index.html file in the top level directory of your submission. For this reason, mkiocccentry(1) will NOT package such files (in the top -level submission directory) and both txzchk(1) and chkentry(1) will flag +level submission directory) and both txzchk(1) and chksubmit(1) will flag them as errors (in the top level submission directory) as well, so please do NOT try and slip these files in the top level directory where your -remarks.md resides. -

    -

    -See the Markdown Cheat Sheet -for a handy quick reference to the Markdown syntax. -

    -

    -See the Markdown guide +remarks.md resides.

    +

    See the Markdown Cheat Sheet +for a handy quick reference to the Markdown syntax.

    +

    See the Markdown guide for free and open-source reference guide that explains -how to use markdown. -

    -

    -See also the Daring Fireball Markdown: +how to use markdown.

    +

    See also the Daring Fireball Markdown: Basics for -information on the markdown format. -

    -

    -PLEASE see our +information on the markdown format.

    +

    PLEASE see our FAQ on “remarks.md” AND the -IOCCC markdown guidelines for additional markdown guidance. -

    +IOCCC markdown guidelines for additional markdown guidance.

    Jump to: top

    Rule 20

    @@ -1149,54 +974,40 @@ FAQ on “remarks.md”

    The how to build instructions must be in GNU Makefile format. See the FAQ about “make(1) compatibility the IOCCC supports for more details.

    -

    -You are ENCOURAGED to use the +

    You are ENCOURAGED to use the Makefile example, renamed as Makefile of course, for help in constructing your Makefile. See the Makefile section in the -guidelines for more details. -

    +guidelines for more details.

    The target of the Makefile must be called prog. The original C source file must be called prog.c.

    To invoke the C compiler, use ${CC}. To invoke the C preprocessor use ${CPP}.

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

    -

    -When make clobber is invoked, we request that your submission directory be restored +

    When make clobber is invoked, we request that your submission directory be restored to its original submission state. For example, any temporary files created during the build process, or during execution should be -removed by the clobber rule. -

    -

    -Your Makefile MUST use a syntax that is compatible with bash(1) +removed by the clobber rule.

    +

    Your Makefile MUST use a syntax that is compatible with bash(1) AND GNU make(1). You are ENCOURAGED to use SHELL= bash in -your Makefile. Please add a space between the = and the value. -

    -

    -Assume that commands commonly found in Single UNIX +your Makefile. Please add a space between the = and the value.

    +

    Assume that commands commonly found in Single UNIX Specification environments and systems that conform to the Single UNIX Specification are -available in the $PATH search path. -

    +available in the $PATH search path.

    Jump to: top

    Rule 21

    -

    -Your submission MUST NOT create or modify files ABOVE the current directory +

    Your submission MUST NOT create or modify files ABOVE the current directory with the exception of the /tmp and the /var/tmp directories. Your submission MAY create subdirectories below the submission directory, or in /tmp, or in /var/tmp provided that . is NOT the first byte in any -directory name or filename you create. -

    -

    -If you do create files and directories, PLEASE be sure that +directory name or filename you create.

    +

    If you do create files and directories, PLEASE be sure that the clobber rule of your Makefile removes such created files -in order to restore your submission to its original submission state. -

    -

    -See also Rule 5. -

    +in order to restore your submission to its original submission state.

    +

    See also Rule 5.

    Jump to: top

    Rule 22

    @@ -1210,11 +1021,9 @@ identify the authors of your code. The judges Peter Honeyman or pretending to be Peter Honeyman) will be grounds for disqualification of your submission.

    -

    -And don’t assume that we won’t be able to determine your name even if it’s not +

    And don’t assume that we won’t be able to determine your name even if it’s not obvious, because you stand a significant chance of violating this rule if you -do. -

    +do.

    Yes, Virginia, WE REALLY MEAN IT!

    Jump to: top

    @@ -1250,60 +1059,42 @@ The IOCCC rule set needs more than 5^2 rul

    Rule 27

    -

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

    +

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

    Jump to: top

    Rule 28

    -

    -Rule 28 is a perfect way to end the list of IOCCC rules -as we do NOT plan to have 496 rules. :-) -

    +

    Rule 28 is a perfect way to end the list of IOCCC rules +as we do NOT plan to have 496 rules. :-)

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

    -

    -PLEASE be SURE you have the current IOCCC rules and -IOCCC guidelines prior to submitting to the contest. -

    +

    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.

    +

    PLEASE be SURE you have the current IOCCC rules and +IOCCC guidelines prior to submitting to the contest.

    See the Official IOCCC website news for additional information.

    -

    -For the updates and breaking IOCCC news, you are encouraged to follow +

    For the updates and breaking IOCCC news, you are encouraged to follow the IOCCC on Mastodon account. See our FAQ on “Mastodon” for more information. Please do note that unless you are mentioned by us you will NOT get a notification from the app so you -should refresh the page even if you do follow us. -

    -

    -Check out the Official IOCCC winner website in general. -

    -

    -Consider joining the IOCCC discord community via this link: -https://discord.gg/Wa42Qujwnw -

    -

    -See the +should refresh the page even if you do follow us.

    +

    Check out the Official IOCCC winner website in general.

    +

    Consider joining the IOCCC discord community via this link: +https://discord.gg/Wa42Qujwnw

    +

    See the FAQ on “obtaining, compiling, installing and using the mkiocccentry tools” and the FAQ on “how to enter the IOCCC” as that FAQ has important details on how to register as well as -how to upload your submission for the IOCCC. -

    +how to upload your submission for the IOCCC.

    Jump to: top

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

    diff --git a/next/rules.md b/next/rules.md index 2703b0682..22205df0d 100644 --- a/next/rules.md +++ b/next/rules.md @@ -48,13 +48,11 @@ Jump to: [top](#)

    -These [IOCCC rules](rules.html) are version **28.30 2025-03-03**. +These [IOCCC rules](rules.html) are version **28.31 2025-11-17**.

    -

    The markdown form of these rules is available for download. -

    **IMPORTANT**: Be sure to read the [IOCCC guidelines](guidelines.html). @@ -131,7 +129,6 @@ This contest will enter the **[judging](../faq.html#judging)** state on **2025-0 of the above **dates and times may change**!

    -

    See the FAQ on "[obtaining and compiling the mkiocccentry tools](../faq.html#mkiocccentry)" and the @@ -140,7 +137,6 @@ as that FAQ has important details on [how to register](../next/register.html) as well as [how to upload your submission](../next/submit.html) to the IOCCC. -

    Jump to: [top](#) @@ -156,7 +152,6 @@ To help us with the volume of submissions, we ask that you follow the rules belo #### A warning about rule abuse
    -

    **WARNING:** Abusing these rules comes with a **fair amount of risk** that your submission will be rejected. If you do plan to abuse the rules, then you **MUST CLEARLY EXPLAIN THE RATIONALE** in your `remarks.md` file, @@ -164,50 +159,38 @@ as to why you think your rule abuse should be allowed, and as to why you think your submission should not be rejected for a rule violation. **Nevertheless, _even if you do_ explain this in your `remarks.md` file you submission may still be rejected**. -

    -

    If you use the most recently released official IOCCC submission packaging tool (hereby referred to as `mkiocccentry(1)`), which we **STRONGLY recommend you do**, then the `mkiocccentry(1)` tool will warn you if there appears to be a violation in certain rules (not all can be detected). The `mkiocccentry(1)` -tool also runs `chkentry(1)` and `txzchk(1)`, the latter of which runs +tool also runs `chksubmit(1)` and `txzchk(1)`, the latter of which runs `fnamchk(1)`. Overriding problems detected by any of these tools comes with a **fair amount of risk** that your submission will be rejected. -

    -

    If you do override a rule violation warning from the `mkiocccentry(1)` or another related IOCCC tool, or otherwise plan to abuse the rules, then you **MUST CLEARLY EXPLAIN THE RATIONALE** of why you are attempting to abuse the rules in your `remarks.md` file. **_Even if you do_ explain this in your `remarks.md` file your submission may still be rejected**. -

    -

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

    -

    + **IMPORTANT**: if you do submit such an alternate non-rule abusing version, **PLEASE** indicate that in your `remarks.md` file of your non-rule abusing version so that the [IOCCC judges](../judges.html) do not think you uploaded a duplicate into a wrong slot by mistake. -

    -

    Uploading a tarball not formed by `mkiocccentry(1)` puts you at a very big risk of violating [Rule 17](rules.html#rule17), especially as `mkiocccentry(1)` does a great number of things that are required, and it also runs many checks, and if any of those checks fail, you are at a very great risk of having your submission rejected for violating [Rule 17](rules.html#rule17). -

    -

    See also [Rule 12](#rule13). -

    Jump to: [top](#) @@ -217,13 +200,9 @@ Jump to: [top](#) ## Rule 0
    -

    Just as C starts at 0, so the IOCCC starts at [Rule 0](#rule0). :-) -

    -

    The "[Important IOCCC dates](#dates)" section above is part of this rule. -

    Jump to: [top](#) @@ -233,16 +212,12 @@ Jump to: [top](#) ## Rule 1
    -

    Your submission must be a C program. -

    -

    You see, the contest is not called the **International Obfuscated JSON Contest** (**IOJSONC**), even if the [so-called JSON spec](https://github.com/xexyl/jparse/blob/master/json_README.md#so-called-json-spec) might be called obfuscated by some people. :-) -

    Jump to: [top](#) @@ -255,31 +230,23 @@ Jump to: [top](#) [Rule 2](#rule2) requires that your submission satisfy **BOTH** [Rule 2a](#rule2a) **AND** [Rule 2b](#rule2b). -

    You may check your code with respect to [Rule 2a](#rule2a) and [Rule 2b](#rule2b) prior to submitting your code by giving the filename as a command like argument to the `iocccsize(1)` tool. For example: -

    ``` iocccsize prog.c ``` -

    The source to `iocccsize(1)` may be found in the [mkiocccentry repo](https://github.com/ioccc-src/mkiocccentry). -

    -

    See also the FAQ on "[how to further test your submission](../faq.html#mkiocccentry_test)" for more more thorough testing, including [Rule 2](#rule2). -

    -

    See also [Rule 2a](#rule2a), [Rule 2b](#rule2b), and [Rule 17](#rule17). -

    Jump to: [top](#) @@ -289,7 +256,7 @@ Jump to: [top](#)

    -The size of your program source **should NOT exceed 4993 bytes**. +The size of your program source **MUST NOT exceed 4993 bytes**.

    Jump to: [top](#) @@ -299,15 +266,11 @@ Jump to: [top](#) ## Rule 2b
    -

    When the filename of your program source is given as a command line argument to the latest version of the official IOCCC size tool (hereby referred to as -`iocccsize(1)`), the value printed **should NOT exceed _2503_**. -

    +`iocccsize(1)`), the value printed **MUST NOT exceed _2503_**. -

    See also [Rule 17](#rule17). -

    Jump to: [top](#) @@ -316,38 +279,27 @@ Jump to: [top](#) ## Rule 3
    -

    You must [register](../next/register.html) in order to submit your entry to the IOCCC. You may [register](../next/register.html) while the contest is either **[pending](../faq.html#pending)** or **[open](../faq.html#open)**. -

    -

    When the contest is **[open](../faq.html#open)**, the [submit server](https://submit.ioccc.org) will email you your [submit server](https://submit.ioccc.org) **Username** and **Initial password**. **Please be patient** as it may take some time, perhaps as much as a few days, for your registration to be processed and for that email to be sent. -

    -

    Those who [register](../next/register.html) while the contest status is **[pending](../faq.html#pending)** will receive their email (containing their [submit server](https://submit.ioccc.org) **Username** and **Initial password**), later: usually a few days around the time when the contest status becomes **[open](../faq.html#open)**. -

    -

    Once that email with your **Username** and **Initial password** is sent, you will have fortnight (**14 days**) to [change your submit server initial password](../next/pw-change.html). -

    -

    If you do not change your **Initial password** in time, you will have to [send email to the IOCCC judges](../contact.md#if-you-really-need-to-send-email-the-ioccc-judges) to ask for your password to be reset. -

    -

    Because it takes time (maybe even a few days) to process your registration and for the server to email you your initial login and password, you should **MAKE SURE** you give yourself enough time to register well @@ -355,18 +307,13 @@ before the contest closes. In other words, **DO NOT WAIT UNTIL THE FINAL DAYS** of the contest to register! The [IOCCC judges](../judges.html) are **NOT** responsible for delayed or lost email, or for those who wait until the last minute to try to register! -

    -

    See the FAQ on "[how to register and submit to the IOCCC](../quick-start.html#enter)" for instructions on registering and participating in the IOCCC, as the process may change from contest to contest. -

    -

    See also [Rule 8](#rule8). -

    Jump to: [top](#) @@ -376,31 +323,21 @@ Jump to: [top](#) ## Rule 4
    -

    If your submission is selected as a winning entry, then your submission may be modified in order to fit into the structure of the [Official IOCCC winner website](https://www.ioccc.org/index.html). -

    -

    For example, your submission's `Makefile` will be modified and your `remarks.md` will become a `README.md` which will be used to generate an `index.html` file. -

    -

    Your source code will be the file `prog.c`. The compiled binary will be called `prog`. If you submission requires different filenames, then modify your submission's `Makefile` to **COPY** (**NOT** move!) the files accordingly. -

    -

    Of course your program may also do this, as long as it works, but you're welcome to use your `Makefile` as well. -

    -

    See also [Rule 5](#rule5), [Rule 18](#rule18) and [Rule 21](#rule21). -

    Jump to: [top](#) @@ -417,16 +354,12 @@ part of your original submission including, but not limited to `prog.c`, the If you submission needs (or wishes :-) ) to modify such content, it **MUST** first copy the file to a new filename and then modify that copy. -

    You may use your submission (program) to form a copy, or you can make use of your `Makefile` to form that copy. -

    -

    If you do make a copy of a submission file, **PLEASE** be sure that the `clobber` rule of your `Makefile` removes that copy in order to restore your submission to its original submission state. -

    Jump to: [top](#) @@ -436,15 +369,11 @@ Jump to: [top](#) ## Rule 6 -

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

    -

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

    Jump to: [top](#) @@ -454,42 +383,31 @@ Jump to: [top](#) ## Rule 7 -

    The obfuscated C program must be your own original work. -

    -

    You (the author(s)) **MUST** own the contents of your submission **OR** you **MUST** have permission from the owner(s) to submit their content. -

    -

    If you submit any content that is owned by others, you **MUST detail that ownership** (i.e., who owns what) **_AND_ document the permission you obtained from them**, in your `remarks.md` file. -

    -

    Please note that the tools in [mkiocccentry repo](https://github.com/ioccc-src/mkiocccentry) are **NOT** original works, unless of course you're the original authors, in which case they are original. :-) -

    -

    Nevertheless tools such as those listed are **NOT** obfuscated. If submitted, they would probably violate a number of rules. :-) -

    - [mkiocccentry(1)](https://github.com/ioccc-src/mkiocccentry/blob/master/mkiocccentry.c) - [iocccsize(1)](https://github.com/ioccc-src/mkiocccentry/blob/master/iocccsize.c) -- [chkentry(1)](https://github.com/ioccc-src/mkiocccentry/blob/master/chkentry.c) +- [chksubmit(1)](https://github.com/ioccc-src/mkiocccentry/blob/master/chksubmit.c) - [txzchk(1)](https://github.com/ioccc-src/mkiocccentry/blob/master/txzchk.c) - [location(1)](https://github.com/ioccc-src/mkiocccentry/blob/master/soup/location_main.c) - [jparse repo as cloned by the mkiocccentry repo](https://github.com/xexyl/jparse) - [dbg repo as cloned by the mkiocccentry repo](https://github.com/lcn2/dbg) - [dyn_array repo as cloned by the mkiocccentry repo](https://github.com/lcn2/dyn_array) -

    The IOCCC has a rich history of remarkable winning entries created by authors who skillfully employed various techniques to develop their code. While it is **NOT** required, you are _allowed_ to use tools to develop @@ -499,11 +417,8 @@ runtime analysis tools, machine learning tools, natural language models, code copilot tools, so-called AI services, large language models (LLMs), etc. If you do make use of such tools or services, then we **ENCOURAGE you to describe what tools and how you used those tools**, in your `remarks.md` file. -

    -

    See also [Rule 5](#rule5), [Rule 18](#rule18) and [Rule 21](#rule21). -

    Jump to: [top](#) @@ -513,64 +428,44 @@ Jump to: [top](#) ## Rule 8 -

    Submissions may only be uploaded to the [IOCCC submit server](https://submit.ioccc.org) while the contest is **[open](../faq.html#open)**. -

    -

    If you have [registered](../next/register.html) and received by email your [submit server](https://submit.ioccc.org) **Username** and **Initial password** you may upload your submission to the [submit server](https://submit.ioccc.org) but **ONLY** while the contest is **[open](../faq.html#open)**. -

    -

    The [submit server](https://submit.ioccc.org), in accordance with [Rule 17](rules.html#rule17), places a limit of **3999971** bytes on the size of your upload. -

    -

    Once the contest is in the **[judging](../faq.html#judging)** state (or **[closed](../faq.html#closed)** state), you may **NOT** upload submissions. -

    -

    While the contest is **[open](../faq.html#open)** or in the **[judging](../faq.html#judging)** state, the [IOCCC judges](../judges.html) **MAY** (but are not required to) modify the slot comment of your submission to indicate that they have received it. If uploaded submission is malformed, the [IOCCC judges](../judges.html) **MAY** (but are not required to) modify the slot comment accordingly. -

    -

    You are **STRONGLY** advised to use the `mkiocccentry(1)` tool as found in the [mkiocccentry repo](https://github.com/ioccc-src/mkiocccentry) to form the file to upload to the [submit server](https://submit.ioccc.org). -

    -

    The [submit server](https://submit.ioccc.org) will become active when the contest is **[open](../faq.html#open)**. Until the contest status becomes **[open](../faq.html#open)**, the [submit server](https://submit.ioccc.org) may be offline and/or unresponsive. -

    -

    See the FAQs on "[obtaining, compiling, installing and using the latest release of the mkiocccentry tools](../faq.html#mkiocccentry)" for more information about the `mkiocccentry(1)` tool. -

    -

    See the "[Important IOCCC dates](#dates)" section above for when these contest states are scheduled. -

    -

    See also [Rule 3](#rule3) and [Rule 17](#rule17). -

    Jump to: [top](#) @@ -580,17 +475,13 @@ Jump to: [top](#) ## Rule 9 -

    Each **PERSON** may register **ONLY ONE** account and each account may submit up to and including **10.000000** (ten in base 10) submissions **PER** contest. -

    **Each submission _must be submitted separately_**. -

    If this seems unreasonable we suggest you wait until the next contest and in the interim ponder this (modified or not) quote said by Bill Gates: -

    > 640K submissions ought to be enough for anybody. > @@ -622,15 +513,11 @@ you expect on our test platforms. If your program needs special permissions you **MUST** document this fact, and explain why it is needed in your submission's `remarks.md` file. -

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

    -

    See also [Rule 17](#rule17). -

    Jump to: [top](#) @@ -644,9 +531,7 @@ the opinion of the [judges](../judges.html), violates the rules WILL BE DISQUALI Submissions that attempt to abuse the rules **MUST** try to justify why their rule abuse is legal, in the `remarks.md` file. -

    See also [the warning about rule abuse](#rule_abuse). -

    Jump to: [top](#) @@ -655,14 +540,10 @@ Jump to: [top](#) ## Rule 13 -

    7 out of 13 UTF-8 characters in C code agree that this rule number is lucky enough to be a prime number. -

    -

    Fun fact: the fear of the number 13 is called _triskaidekaphobia_. -

    Jump to: [top](#) @@ -672,30 +553,22 @@ Jump to: [top](#) ## Rule 14 -

    Any C source that fails to compile because of lines with trailing control-M's (i.e., lines with a trailing byte `015`) **might** be rejected. -

    -

    Please do **NOT** put trailing control-M's on `prog.c`, `Makefile`, or `remarks.md` files but instead end lines with a trailing newline (i.e., byte `012`) character. -

    -

    As we do **NOT** use DOS, please also be sure that the `Makefile` and `remarks.md` files end in final newline (i.e., byte `012`) character. -

    -

    You are permitted, in order to try and squeeze your `prog.c` under a [Rule 2a](#rule2a) and/or [Rule 2b](#rule2b) limit, to **NOT** end your `prog.c` with a newline (i.e., byte `012`) character. If you need to do this, **PLEASE** document that in your `remarks.md` file and if your compiler complains about this, document this too and update your `Makefile` to account for this. -

    Jump to: [top](#) @@ -705,20 +578,14 @@ Jump to: [top](#) ## Rule 15 -

    In order to register for the IOCCC, you **MUST** have a valid email address. -

    -

    The [judges](../judges.html) **are NOT responsible for delays in email**, so please plan enough time accordingly. -

    -

    See the FAQ on "[how to register](../quick-start.html#register)" for details. -

    Jump to: [top](#) @@ -730,22 +597,18 @@ Jump to: [top](#) Submissions that are similar to previous winning IOCCC entries are discouraged. -

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

    -

    Resubmitting an improved submission that did not become an IOCCC winning entry is a **time honored** tradition of the IOCCC. There are some IOCCC winning entries that were submitted to multiple contests before they were improved enough to "climb over" (as the expression goes) all the other submissions for a given contest. -

    Jump to: [top](#) @@ -754,68 +617,57 @@ Jump to: [top](#) ## Rule 17 -

    Your submission must be in the form of a **xz compressed tarball** that the **current released version** of the `mkiocccentry(1)` tool would generate. The files, directories, and paths **MUST** conform to the limits imposed by `mkiocccentry(1)` including but **NOT LIMITED** to their names, count, path length, directory tree depth and permissions. -

    -

    Your **xz compressed tarball** must be larger than **0** bytes and no larger than **3999971** bytes. -

    -

    The sum of the byte lengths of all files, after the **xz compressed tarball** is untarred, must **NOT** exceed `27651*1024` bytes. -

    -

    Your **xz compressed tarball** submission _file_ **MUST** pass the tests performed by the current version of `txzchk(1)`. -

    -

    Your **xz compressed tarball** submission _filename_ **MUST** pass the tests performed by the current version of `fnamchk(1)`. -

    -

    When your **xz compressed tarball** submission file is untarred, the resulting _directory_ **MUST** pass the checks performed by the current version -of `chkentry(1)`. -

    +of `chksubmit(1)`. -

    The resulting `prog.c` file **MUST** pass the [Rule 2](#rule2) size checks performed by the current version of `iocccsize(1)`. -

    -

    The `.auth.json` and `.info.json` **MUST** be compatible with what the current version of the `mkiocccentry(1)` tool would produce. They **MUST -ALSO** pass the tests performed by the current version of `chkentry(1)`. -

    +ALSO** pass the tests performed by the current version of `chksubmit(1)`. -

    The required `Makefile` must **NOT** be empty. -

    -

    The required `remarks.md` must **NOT** be empty. -

    -

    You may **NOT** submit a tarball created by the `-d` or `-s seed` option of `mkiocccentry(1)`. -

    The maximum number of files your submission tarball may contain, not counting -the optional files (`prog.alt.c`, `try.sh`, `try.alt.sh`) and the mandatory -files (`prog.c`, `Makefile`, `remarks.md`) is 31. +the free files (`prog.c`, `remarks.md`, `Makefile`, `prog.alt.c`, `try.sh`, +`try.alt.sh` and the two files generated by `mkiocccentry`, `.info.json` and +`.auth.json`) is 31. +

    + +

    +The maximum number of directories your submission may have is 13 and the maximum +depth a path may have is 4. +

    + +

    +The maximum filename length (a component of a path) is 38 which means the +maximum length total of a path is 60 characters.

    See the @@ -825,31 +677,23 @@ for more details. ### TL;DR Rule 17 - Use `mkiocccentry(1)` to form your submission -

    Let the current version of the `mkiocccentry(1)` tool form your **xz compressed tarball** submission file. -

    ### Warning -

    Using command line flags or input prompts to override checks and limits made by the above mentioned tools is **NOT** recommended and may result in your submission being rejected by the [IOCCC submit server](https://submit.ioccc.org) and/or the [IOCCC Judges](../judges.html). -

    -

    See the FAQ on the "[mkiocccentry toolkit](../faq.html#mkiocccentry) for how to obtain and use the above mentioned tools. -

    -

    **IMPORTANT**: See the FAQ on "[Rule 17](../faq.html#rule17)" for very important details behind this rule. -

    Jump to: [top](#) @@ -863,9 +707,7 @@ The entirety of your submission must be submitted under the following license: > **[CC BY-SA 4.0 DEED Attribution-ShareAlike 4.0 International](https://creativecommons.org/licenses/by-sa/4.0/)** -

    See also [Rule 7](#rule7). -

    Jump to: [top](#) @@ -875,52 +717,38 @@ Jump to: [top](#) ## Rule 19 -

    The `remarks.md` file, a required non-empty file, must be written in [Markdown format](https://www.markdownguide.org/basic-syntax/). -

    -

    We currently use [pandoc(1)](https://pandoc.org) to automatically convert markdown to HTML. Please try to avoid submitting an HTML file translation to any markdown file. If you **MUST** submit such an HTML translation, **PLEASE** mention this in your `remarks.md` file. -

    -

    For any submission that wins the contest, we modify your `remarks.md` file and rename it as `README.md` and then use [pandoc(1)](https://pandoc.org) to generate the `index.html` file in the top level directory of your submission. For this reason, `mkiocccentry(1)` will **NOT** package such files (in the top -level submission directory) and both `txzchk(1)` and `chkentry(1)` will flag +level submission directory) and both `txzchk(1)` and `chksubmit(1)` will flag them as errors (in the top level submission directory) as well, so please do **NOT** try and slip these files in the top level directory where your `remarks.md` resides. -

    -

    See the [Markdown Cheat Sheet](https://www.markdownguide.org/cheat-sheet/) for a handy quick reference to the Markdown syntax. -

    -

    See the [Markdown guide](https://www.markdownguide.org) for free and open-source reference guide that explains how to use markdown. -

    -

    See also the [Daring Fireball Markdown: Basics](http://daringfireball.net/projects/markdown/basics) for information on the markdown format. -

    -

    **PLEASE** see our FAQ on "[remarks.md](../faq.html#remarks_md)" **AND** the [IOCCC markdown guidelines](../markdown.html) for additional markdown guidance. -

    Jump to: [top](#) @@ -934,12 +762,10 @@ The how to build instructions must be in GNU Makefile format. See the FAQ about "[make(1) compatibility the IOCCC supports](../faq.html#make_compatibility) for more details. -

    You are **ENCOURAGED** to use the Makefile example, renamed as `Makefile` of course, for help in constructing your `Makefile`. See the [Makefile section](guidelines.html#makefile) in the guidelines for more details. -

    The target of the `Makefile` must be called `prog`. The original C source file must be called `prog.c`. @@ -949,26 +775,20 @@ To invoke the C compiler, use `${CC}`. To invoke the C preprocessor use Do **NOT** assume that `.` (the current directory) is in the `$PATH`. -

    When `make clobber` is invoked, we request that your submission directory be restored to its original submission state. For example, any temporary files created during the build process, or during execution should be removed by the `clobber` rule. -

    -

    Your `Makefile` **MUST** use a syntax that is compatible with `bash(1)` **AND** GNU `make(1)`. You are **ENCOURAGED** to use `SHELL= bash` in your `Makefile`. Please add a space between the `=` and the value. -

    -

    Assume that commands commonly found in [Single UNIX Specification](https://en.wikipedia.org/wiki/Single_UNIX_Specification) environments and systems that conform to the [Single UNIX Specification](https://en.wikipedia.org/wiki/Single_UNIX_Specification) are available in the `$PATH` search path. -

    Jump to: [top](#) @@ -978,23 +798,17 @@ Jump to: [top](#) ## Rule 21 -

    Your submission **MUST NOT** create or modify files **ABOVE** the current directory _with the exception of_ the `/tmp` and the `/var/tmp` directories. Your submission **MAY** create subdirectories **below** the submission directory, or in `/tmp`, or in `/var/tmp` provided that `.` is **NOT** the first byte in any directory name or filename you create. -

    -

    If you do create files and directories, **PLEASE** be sure that the `clobber` rule of your `Makefile` removes such created files in order to restore your submission to its original submission state. -

    -

    See also [Rule 5](#rule5). -

    Jump to: [top](#) @@ -1017,11 +831,9 @@ within your code, data, remarks or program output (unless you are **Peter Honeyman** or pretending to be **Peter Honeyman**) will be grounds for disqualification of your submission. -

    And don't assume that we won't be able to determine your name even if it's not obvious, because you stand a significant chance of violating this rule if you do. -

    Yes, Virginia, **WE REALLY MEAN IT!** @@ -1080,9 +892,7 @@ Jump to: [top](#) ## Rule 27 -

    Unless otherwise needed, [Rule 27](#rule27) is reserved for something cubic. :-) -

    Jump to: [top](#) @@ -1092,10 +902,8 @@ Jump to: [top](#) ## Rule 28 -

    [Rule 28](#rule28) is a perfect way to end the list of [IOCCC rules](rules.html) as we do **NOT** plan to have **496** rules. :-) -

    Jump to: [top](#) @@ -1106,41 +914,28 @@ Jump to: [top](#) -

    For questions or comments about the contest, see [Contacting the IOCCC](../contact.html). -

    -

    **Be SURE** to review the [IOCCC Rules and Guidelines](index.html) as they may (and **often do**) change from year to year. -

    -

    **PLEASE** be **SURE** you have the **current** [IOCCC rules](rules.html) and [IOCCC guidelines](guidelines.html) prior to submitting to the contest. -

    See the [Official IOCCC website news](../news.html) for additional information. -

    For the updates and breaking IOCCC news, you are encouraged to follow the [IOCCC on Mastodon](https://fosstodon.org/@ioccc) account. See our FAQ on "[Mastodon](../faq.html#try_mastodon)" for more information. Please do note that unless you are mentioned by us you will **NOT** get a notification from the app _so you should refresh the page **even if you do follow us**_. -

    -

    Check out the [Official IOCCC winner website](https://www.ioccc.org/index.html) in general. -

    -

    Consider joining the IOCCC discord community via this link: [https://discord.gg/Wa42Qujwnw](https://discord.gg/Wa42Qujwnw) -

    -

    See the FAQ on "[obtaining, compiling, installing and using the mkiocccentry tools](../faq.html#mkiocccentry)" and the @@ -1149,7 +944,6 @@ as that FAQ has important details on [how to register](../next/register.html) as well as [how to upload your submission](../next/submit.html) for the IOCCC. -

    Jump to: [top](#) diff --git a/next/submit.html b/next/submit.html index c85b17781..4c18569e9 100644 --- a/next/submit.html +++ b/next/submit.html @@ -495,7 +495,7 @@ of:

    timestamp.

    We highly recommend that you use mkiocccentry(1) to create your submit file as it must pass the txzchk(1) sanity checks, and when the uncompressed tarball is -untarred, the resulting directory must pass chkentry(1).

    +untarred, the resulting directory must pass chksubmit(1).

    NOTE: the 00000000-0000-4000-0000-000000000000 is your UUID. MAKE SURE YOU CHANGE IT TO YOUR UUID!

    @@ -571,7 +571,7 @@ To see any status updates, you should logout and log back in later.

    Or:

    -

    Status: submit file failed the chkentry test! Use mkiocccentry to rebuild and resubmit to this slot.

    +

    Status: submit file failed the chksubmit test! Use mkiocccentry to rebuild and resubmit to this slot.

    … or ANY other error then you MUST FIX your submission, repackage your tarball with mkiocccentry and upload to the same slot again! If you do not fix @@ -579,7 +579,7 @@ this your submission WILL BE REJECTED for violating Rule 17, even tests passed.

    For details on txzchk, see the FAQ on “txzchk”.

    -

    For details on chkentry, see the -FAQ on “chkentry”.

    +

    For details on chksubmit, see the +FAQ on “chksubmit”.

    If you need more information on the two JSON files, see FAQ on the “.info.json file” and the diff --git a/next/submit.md b/next/submit.md index 2b015ad89..b0b340e9c 100644 --- a/next/submit.md +++ b/next/submit.md @@ -56,7 +56,7 @@ timestamp](https://unixtime.org/). > > We highly recommend that you use `mkiocccentry(1)` to create your submit file as it must pass the `txzchk(1)` sanity checks, and when the uncompressed tarball is -untarred, the resulting directory must pass `chkentry(1)`. +untarred, the resulting directory must pass `chksubmit(1)`. **NOTE**: the `00000000-0000-4000-0000-000000000000` is your UUID. **MAKE SURE YOU CHANGE IT TO YOUR UUID**! @@ -153,7 +153,7 @@ After the format test is complete, if you see an error such as: Or: -> **Status: submit file failed the chkentry test! Use mkiocccentry to rebuild and resubmit to this slot.** +> **Status: submit file failed the chksubmit test! Use mkiocccentry to rebuild and resubmit to this slot.** ... or **ANY** other error then you **MUST FIX** your submission, repackage your tarball with `mkiocccentry` and upload to the same slot again! If you do not fix @@ -162,7 +162,7 @@ this your submission **WILL BE REJECTED** for violating [Rule If the format test went well, then you will see: -> **Status: submit file received by the IOCCC judges. Passed both txzchk and chkentry tests.** +> **Status: submit file received by the IOCCC judges. Passed both txzchk and chksubmit tests.** **IMPORTANT**: this does **NOT** mean that your submission does not violate the rules or that everything is OK once the tarball is extracted; it simply means @@ -174,8 +174,8 @@ tests passed. For details on `txzchk`, see the FAQ on "[txzchk](../faq.html#txzchk)". -For details on `chkentry`, see the -FAQ on "[chkentry](../faq.html#chkentry)". +For details on `chksubmit`, see the +FAQ on "[chksubmit](../faq.html#chksubmit)". If you need more information on the two JSON files, see FAQ on the [".info.json file](../faq.html#info_json)" diff --git a/quick-start.html b/quick-start.html index f9fec3c93..53321d71e 100644 --- a/quick-start.html +++ b/quick-start.html @@ -577,7 +577,7 @@ you have an earlier version and you have not installed the tools and run the tools from outside the repo directory, you will have to use the options to the tools to set the path to the required tools.

    Do remember to make sure you have the latest vers -chkentry(1), txzchk(1) and fnamchk(1). And remember to make sure you have +chksubmit(1), txzchk(1) and fnamchk(1). And remember to make sure you have the latest version so you do not violate Rule 17. See the FAQ on “obtaining the latest mkiocccentry tools”, diff --git a/quick-start.md b/quick-start.md index 9adb35a77..78d4212bc 100644 --- a/quick-start.md +++ b/quick-start.md @@ -177,7 +177,7 @@ tools from outside the repo directory, you will have to use the options to the tools to set the path to the required tools. Do remember to make sure you have the latest vers -`chkentry(1)`, `txzchk(1)` and `fnamchk(1)`. And remember to make sure you have +`chksubmit(1)`, `txzchk(1)` and `fnamchk(1)`. And remember to make sure you have the latest version so you do not violate [Rule 17](next/rules.html#rule17). See the FAQ on "[obtaining the latest mkiocccentry tools](faq.html#obtaining_mkiocccentry)",