From 03b4248dd2a97018ef216d99bf86e47c6250e068 Mon Sep 17 00:00:00 2001 From: Cody Boone Ferguson <53008573+xexyl@users.noreply.github.com> Date: Thu, 23 Jan 2025 11:59:16 -0800 Subject: [PATCH 1/2] Many fixes and other updates to guidelines This includes typos, fixing terms (according to the new terminology used by the IOCCC) and various other types of fixes. Although I have gone through the entire file more does need to be done to make sure it all reads okay and that all links are correct. --- next/guidelines.html | 539 ++++++++++++++++++++++++------------------- next/guidelines.md | 532 ++++++++++++++++++++++++------------------ 2 files changed, 608 insertions(+), 463 deletions(-) diff --git a/next/guidelines.html b/next/guidelines.html index dbb8d1a33..c0032735e 100644 --- a/next/guidelines.html +++ b/next/guidelines.html @@ -492,9 +492,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.

-

You should read the current IOCCC rules, prior to submitting -entries. The rules are typically published along with the IOCCC -guidelines..

+

You SHOULD read the CURRENT IOCCC rules, prior to submitting +code to the contest. The rules are typically published along with +the IOCCC guidelines.

Jump to: top

WHAT’S NEW THIS IOCCC

@@ -514,7 +514,7 @@ This contest will enter the judging

IMPORTANT NOTE: Until the content enters the open state, any or all -of the above dates and times may change! +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 @@ -524,100 +524,70 @@ to be a functional UTC time. :-) 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 +mkiocccentry repo, SHOULD be +considered provisional BETA versions and may be adjusted AT ANY TIME before the contest status becomes open.

-You MUST register in order to submit your entry to the IOCCC. +You MUST register in order to participate in the IOCCC. You may register while the contest is either pending or 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 has changed from previous years! +for instructions on registering and participating in the IOCCC, as the process +has changed from previous years!

-When the contest is open, an -IOCCC judge will email you your submit server -Username and Initial password. This takes some time (maybe even a few days) for an -IOCCC judge to process your registration and email you your -initial login and password. +When the contest is open, an IOCCC +judge will email you your submit +server Username and Initial password. This +takes some time (maybe even a few days) for an IOCCC judge to +process your registration and email you your initial login and password, so be +sure to give yourself enough time.

-Those who register while the contest status is pending -will receive email with their submit server Username and Initial password -from an IOCCC judge shortly after the contest status becomes open. +Those who register while the contest status is +pending will receive email with their submit +server Username and Initial password from an +IOCCC judge shortly after the contest status becomes +open.

Once an IOCCC judge emails you your Username and Initial password, you will have 72 hours to change your submit server initial password. -If you do not change your Initial password in time, you will have to re-register. +If you do not change your Initial password in time, you will have to +re-register. You may NOT upload any submission until you +have changed your Initial password and logged back in!

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

-For those who have registered and received by email, their +Once you have registered, and received by email, your submit server Username and Initial password -from an IOCCC judge, you may upload your submission to -the submit server only while the -contest open. +from an IOCCC judge, you may, after changing your initial +password upload your submission to +the submit server, as long as the contest +open. +

+

+The submit server will become active when the +contest is pending. +Until the contest status becomes pending, +the submit server might be offline and/or unresponsive.

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

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

-

-See the -FAQ on “obtaining and compiling the mkiocccentry tools” -for more information about the mkiocccentry(1) tool. -

-

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

-

-To help you with this, 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. -

-

-Once the contest enters the judging state, you will -NOT be allowed to upload your submission files. -

-

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

-

-The Rule 2a size has increased from 4096 to 4993 bytes. -

-

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

-

-The new default way to compile submissions: -std=gnu17 -O3 -g3 -Wall -Wextra -pedantic. -You are encouraged to use the example Makefile here. For more details and help, -see below in the Makefile section. -

-

Submissions are uploaded as a single xz compressed tarball.

@@ -625,10 +595,6 @@ To assist in the formation of the xz compressed tarball for submission, use the mkiocccentry(1) tool as found in the mkiocccentry repo.

-Rule 17 has been significantly modified -to account for the new mkiocccentry repo tools. -

-

If you wish to test that your submission passes the mkiocccentry(1) tests without having to put 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. @@ -641,92 +607,41 @@ that if the directory exists already, you will have to remove it or move it before this option will work a second time, just like in normal mode.

+Rule 17 has been significantly modified +to account for the new mkiocccentry repo tools. +Thus, 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. Not +doing so puts you at a very big risk of violating Rule 17. +

+

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

-

Jump to: top

-
-
-

HINTS AND SUGGESTIONS:

-
-
-

You are encouraged to examine the winners of previous contests.

-

Keep in mind that rules change from year to year, so some winning -entries might not be valid submissions this year; what was unique -and novel one year might be ‘old’ the next year.

-

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

- -

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

-

Your submission need not pass all of the above tests. In certain -cases, a test is not important. Entries that compete for the -‘strangest/most creative source layout’ need not do as well as -others in terms of their algorithm. On the other hand, given -two such entries, we are more inclined to pick the submission that -does something interesting when you run it.

-

We try to avoid limiting creativity in our rules. As such, we -leave the contest open for creative rule interpretation. As in real -life programming, interpreting a -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.

-

We do realize that there are holes in the rules, and invite -entries to attempt to exploit them. We will 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 -guidelines, we will attempt to use a very small plug, if not -smaller. Or, maybe not. :-) +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.

-There may be fewer than 2^7+1 reasons why these IOCCC -guidelines seem obfuscated. +To help you with this, 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!

-

Check out your program and be sure that it works. We sometimes make -the 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 -of the best entries fall down because they didn’t work.

-We tend to look down on a prime -number printer that claims that -16 is a prime number. If you do have a bug, you are better off -documenting it. Noting “this submission sometimes prints the 4th power -of a prime by mistake” would save the above submission. And sometimes, -a strange bug/feature can even help the submission! Of course, a correctly -working submission is best. 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. +Once the contest enters the judging state, you will +NOT be allowed to upload your submission files, so do give yourself enough +time.

-

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.

-

Ultra-obfuscated programs are, in some cases, easier to -deobfuscate than subtly-obfuscated programs. Consider using -misleading or subtle tricks layered on top of or under an -appropriate level of obfuscation. A clean looking program with -misleading comments and variable names might be a good start.

-

When programs use VTxxx/ANSI sequences, they should NOT be limited to a -specific terminal brand. Those programs that work in a standard xterm -are considered more portable.

Rule 2 (the size rule) refers to the use of the IOCCC size tool called iocccsize(1). @@ -740,18 +655,31 @@ To further clarify Rule 2, we subdivided it into 2a and 2b.

-The overall size limit (see Rule 2a) on prog.c is now 4993 bytes. +The overall size limit (see Rule 2a) on prog.c has been +increased from 4096 to 4993 bytes.

-Your submission must satisfy BOTH the maximum size Rule +The Rule 2a size was changed from +4096 to 4993: a change that keeps the “2b to 2a” size ratio to a +value similar to the 2001-2012 and +2013-2020 IOCCC eras. +

+

+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 tool Rule 2b.

-This IOCCC size tool imposes a 2nd limit on C code size (see Rule +The IOCCC size tool imposes a 2nd limit on C code size (see Rule 2a). To check your code against Rule 2: 

    iocccsize prog.c
-

The IOCCC size tool algorithm may 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 octets as 1 @@ -769,6 +697,10 @@ counted by the IOCCC size tool. This is a feature, not a bug! the IOCCC size tool source code conflict, the algorithm implemented by the IOCCC size tool source code is preferred by the 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. @@ -779,15 +711,111 @@ BESM-6, and 2503 is a decimal anagram of 2053. 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!

+

Jump to: top

+
+
+

HINTS AND SUGGESTIONS:

+
+
+

You are encouraged to examine the winners of previous contests.

+

Keep in mind that rules change from year to year, so some winning +entries might not be valid submissions this year; what was unique +and novel one year might be ‘old’ the next year.

+

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

+
    +
  • look at the original source
    • +

  • +convert ANSI trigraphs and digraphs to normal C +

    • +
  • C pre-process the source ignoring #include lines
    • +
  • C pre-process the source ignoring #define and #include lines
    • +
  • run it through a C beautifier
    • +
  • examine the algorithm
    • +
  • compile it (with flags to enable all warnings)
    • +
  • execute it
    • +
+

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

+

Your submission need not pass all of the above tests. In certain +cases, a test is not important. Entries that compete for the +‘strangest/most creative source layout’ need not do as well as +others in terms of their algorithm. On the other hand, given +two such entries, we are more inclined to pick the submission that +does something interesting when it’s executed.

+

We try to avoid limiting creativity in our rules. As such, we +leave the contest open for creative rule interpretation. As in real +life programming, interpreting a +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 Rule 2a size was changed from -4096 to 4993: a change that keeps the “2b to 2a” size ratio to a -value similar to the 2001-2012 and -2013-2020 IOCCC eras. +Although we are in an age where AI/LLM can create code, we don’t want to stop +anyone from using any tools they like when they’re working on their submissions. +

+

+The IOCCC has a rich history of remarkable winning entries created by authors +who skillfully employed various code-related techniques such as code generators, +code analysis tools, machine learning tools, natural language models, code +copilot tools, and integrated development environments. Although it is NOT +required to use these kinds of tools in order to compile or run a submission, +individuals are free to continue to create their submissions using them. Even +so, we DISLIKE submissions that require an IDE (integrated +development environment). +

+

+There have been instances where winning entry code was quite different from the +original author’s input. At least one winning author cannot even use a +keyboard! +

+

We do realize that there are holes in the rules, and invite +entries to attempt to exploit them. We will 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 +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. +

+

+Check out your program and be sure that it works. 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 +of the best submissions fall down because they didn’t work. +

+

+We tend to look down on a prime +number printer that claims that +16 is a prime number. If you do have a bug or mis-feature, you are better off +documenting it. Noting “this submission sometimes prints the 4th power +of a prime by mistake” would save the above submission. And sometimes, +a strange bug/(mis-)feature can even help the submission! Of course, a correctly +working submission is best. Clever people will note that 16 might be prime +under certain conditions. Wise people, when submitting something clever +will fully explain such cleverness in their submission’s remarks.md file. +

+

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

+

Ultra-obfuscated programs are, in some cases, easier to +deobfuscate than subtly-obfuscated programs. Consider using +misleading or subtle tricks layered on top of or under an +appropriate level of obfuscation. A clean looking program with +misleading comments and variable names might be a good start.

+

+When programs use VTxxx/ANSI sequences, they should NOT be limited to a +specific terminal brand. Programs that work in a standard xterm +are considered more portable.

Jump to: top

-

Including extra files

+

Including optional and extra files

The maximum total number of files that may be submitted has changed to 39 files. @@ -795,7 +823,13 @@ However, of those files, 5 are mandatory (prog.c, Makefilemkiocccentry(1), .info.json and .auth.json). Additionally, three of the files in the limit MUST be specific file(name)s: the OPTIONAL submission files, which are prog.alt.c, -try.sh and try.alt.sh, or else they WILL count as an extra file. +try.sh and try.alt.sh, or else they WILL count as an extra file. Of +course, if you use the optional filenames without the files being their +intended, that would be an abuse of rules. +For more details on the optional files, see the +FAQ on the “try.sh script system” +and the +FAQ on “alt code”.

In other words, the actual amount of EXTRA files is 31. @@ -803,19 +837,18 @@ In other words, the actual amount of EXTRA files is 31.

If you do need to include more files, 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. +submission tarball must pass the txzchk(1) tests. See the txzchk +section for more details on this important tool. +

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

-

See Rule 17 and in particular the part about the maximum +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!

-

-

For more details, see the -FAQ on the “try.sh script system”, -the -FAQ on “.auth.json”, -the -FAQ on “.info.json”,

+are at a great risk of violating Rule 17! +

mkiocccentry

Rule 17 (the mkiocccentry(1) rule) states that @@ -826,9 +859,10 @@ See the mkiocccentry repomkiocccentry(1) tool and below for more details.

-

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

+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. Once the tarball is @@ -839,7 +873,7 @@ its algorithm. If mkiocccentry encounters an error the program will exit and the xz compressed tarball will not be formed. For instance, if chkentry(1) (see below) fails to validate the .auth.json or .info.json -JSON files that mkiocccentry(1) creates, +JSON files (see below) that mkiocccentry(1) creates, it is an error and possibly a bug that you should report as a bug at the mkiocccentry bug report page. @@ -853,11 +887,11 @@ 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 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. Needless to say, we do -NOT recommend these options. +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. +Needless to say, we do NOT recommend these options.

In many places it will prompt you to verify what you input, allowing you to @@ -882,10 +916,12 @@ overwrites the file).

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

-

mkiocccentry tools

+

Other mkiocccentry tools

The mkiocccentry(1) tool will execute a number of tools, some of which will @@ -894,10 +930,11 @@ execute one or more additional tools.

iocccsize

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

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

Jump to: top

chkentry

@@ -1003,7 +1040,7 @@ page. PLEASE run the FAQ on “report mkiocccentry bugs”.

-As part of its sanity checks, txzchk(1) will run fnamchk(1) on the +As part of its algorithm, txzchk(1) will run fnamchk(1) on the filename to verify that the name is valid. See the FAQ on “fnamchk” and fnamchk below for more details on this tool. @@ -1038,7 +1075,7 @@ tarball filename, see the FAQ on “fnamchk”.

-Because txzchk(1) tool uses fnamchk(1) tool as part of its algorithm, +Because txzchk(1) tool uses the fnamchk(1) tool as part of its algorithm, mkiocccentry(1) does not directly invoke fnamchk(1), although we will in the judging process.

@@ -1055,7 +1092,7 @@ FAQ on “report 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 +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 file, the mkiocccentry(1) tool would not package it. But if you were to package @@ -1086,7 +1123,7 @@ that’s OK too!

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