We were pleased to observe that while the IOCCC size limit increased by about 21%, we received many submissions that were well under the new Rule 2 including a fair number of quality diff --git a/next/guidelines.html b/next/guidelines.html index 2c1b2071bd..96ab7b4357 100644 --- a/next/guidelines.html +++ b/next/guidelines.html @@ -456,19 +456,21 @@
All Rights Reserved. Permission for personal, education or non-profit use is -granted provided this copyright and notice are included in its entirety -and remains unaltered. All other uses must receive prior permission in -writing by contacting the Judges.
+All Rights Reserved. Permission for personal, education or non-profit +use is granted provided this copyright and notice are included in its +entirety and remains unaltered. All other uses must receive prior +permission in writing by contacting the Judges.
Be sure to read the Rules.
prog.c
-file happens to also be a code for another language.
+While you submission MUST be a C program, there is nothing wrong if
+your prog.c file happens to also be a code for another language, say
+an interpreter of JavaScript.
Jump to: top
Your submission must satisfy BOTH the Rule 2a - Gross Size AND Rule 2b - Net Size rules.
To check your code against
-Rule 2 - Size restrictions, use the iocccentry(1) tool.
-For example:
iocccentry(1) tool. For example:
iocccsize prog.cThe iocccsize(1) algorithm can be summarized as follows:
-The size tool counts most C reserved words (keyword, secondary, and selected -preprocessor keywords) as 1. The size tool counts all other bytes as 1 -excluding ASCII whitespace, and excluding any ‘
-;’, ‘{’ or ‘}’ followed by -ASCII whitespace, and excluding any ‘;’, ‘{’ or ‘}’ byte immediately -before the end of file.ASCII whitespace includes ASCII tab, ASCII space, ASCII newline, ASCII formfeed, and ASCII carriage return.
-When ‘
+;’, ‘{’ or ‘}’ are within a C string, they may still not be -counted by the IOCCC size tool.The size tool counts most C reserved words (keyword, secondary, and +selected preprocessor keywords) as 1. The size tool counts all other +bytes as 1 excluding ASCII whitespace, and excluding any ‘
+;’, ‘{’ +or ‘}’ followed by ASCII whitespace, and excluding any ‘;’, ‘{’ +or ‘}’ byte immediately before the end of file.ASCII whitespace includes ASCII tab, ASCII space, ASCII newline, +ASCII formfeed, and ASCII carriage return.
+When ‘
;’, ‘{’ or ‘}’ are within a C string, they may still not +be counted by the IOCCC size tool.
In cases where the above summary and the algorithm implemented by
-iocccsize(1) conflict, the algorithm implemented
-by the minimum required version of iocccsize(1) is preferred by the Judges.
iocccsize(1) conflict, the algorithm implemented by the minimum
+required version of iocccsize(1) is preferred by the
+Judges.
Make sure iocccsize does not flag any issues with your prog.c.
NOTE: by default iocccsize will only report the size, unless the
code surpasses the limit.
There a much less need to #define C reserved words in an effort
-to get around the size limits of
-Rule 2 - Size restrictions
-because of the iocccsize(1) algorithm.
There a much less need to #define C reserved words in an effort to
+get around the size limits of Rule 2 - Size
+restrictions because of the iocccsize(1)
+algorithm.
Yes Virginia, the previous guideline sentence is an important hint!
Don’t expect the Rule 2 - Size restrictions to change any time soon.
-See the -FAQ on “How has the Rule 2 size restrictions rule changed over the years?”.
+See the FAQ on “How has the Rule 2 size restrictions rule changed over +the years?”.
Jump to: top
It can take a few days to process your registration and for the server to -email your details, therefore make sure to allow yourself ample time to -register and submit your entries; DO NOT WAIT UNTIL THE FINAL DAYS -to register! The Judges are NOT responsible for delayed or lost -email or for those who wait until the last minute to try to register!
+It can take a few days to process your registration and for the server +to email your details, therefore make sure to allow yourself ample time +to register and submit your entries; DO NOT WAIT UNTIL THE FINAL +DAYS to register! The Judges are NOT responsible for delayed or +lost email or for those who wait until the last minute to try to +register!
-See How to register for the IOCCC.
-See Entering the IOCCC: the bare minimum you need to know.
+See the +FAQ on “How to register for the IOCCC”.
+See the +FAQ on “Entering the IOCCC: the bare minimum you need to +know”.
Jump to: top
While it is NOT required, you are allowed to use tools or services such as:
+While it is NOT required, you are allowed to use tools or services +such as:
See the -FAQ on “May I use AI, LLM, Virtual coding assistants, or similar tools to write my submission?”.
+FAQ on “May I use AI, LLM, Virtual coding assistants, or similar tools +to write my submission?”.Jump to: top
Do NOT register more than one account just to try and get around the limit on the number of submission slots.
+Do NOT register more than one account just to try and get around +the limit on the number of submission slots.
Jump to: top
Don’t forget that the building of your program should be done -WITHOUT human intervention. So don’t do things such as:
+Don’t forget that the building of your program should be done WITHOUT +human intervention. So don’t do things such as:
prog: prog.c
#echo this next line requires data from standard input
cat > prog.c
${CC} prog.c -o progHowever, you can do something cute such as making your program
-do something dumb (or cute) when it is built ‘automatically’, and
-when it is run with a human involved, do something more clever.
-For example, one could put in their Makefile:
However, you can do something cute such as making your program do
+something dumb (or cute) when it is built ‘automatically’, and when it
+is run with a human involved, do something more clever. For example,
+one could put in their Makefile:
prog: prog.c
${CC} prog.c -DNON_HUMAN_COMPILE -o prog
@echo "See remarks section about alternate ways to compile"and then include special notes in your remarks.md file for
-alternate / human intervention based building.
and then include special notes in your remarks.md file for alternate
+/ human intervention based building.
Jump to: top
We do realize that there are holes in the Rules, and invite -submitters to attempt to apply creative rule interpretation. A rule abuse though, even -if not rewarded, may result in a subsequent rule change for future contests.
-We sometime award ‘Best abuse of the rules’ or ‘Worst abuse of the rules’, -or some variation, to a submission that creatively attempts to exploit a holes in the -Rules.
-When we do need to plug a hole in the Rules -or Guidelines, we will attempt to use a very small plug, -if not smaller.
+We do realize that there are holes in the Rules, and +invite submitters to attempt to apply creative rule interpretation. A +rule abuse though, even if not rewarded, may result in a subsequent +rule change for future contests.
+We sometime award ‘Best abuse of the rules’ or ‘Worst abuse of +the rules’, or some variation, to a submission that creatively +attempts to exploit a holes in the Rules.
+When we do need to plug a hole in the Rules or +Guidelines, we will attempt to use a very small +plug, if not smaller.
Or, maybe not. :-)
-Legal rule abuse may involve, but is not limited to, doing things that are -technically allowed by the Rules and yet do not fit the spirit of what -we intended to be submitted.
-Legal abuse of the Rules is NOT an invitation to violate -the Rules (especially Rule 17 - -Use mkiocccentry). A submission that violates the -rules in the opinion of the Judges, -WILL be disqualified. RULE ABUSE CARRIES A CERTAIN LEVEL OF RISK!
-If you intend to abuse the Rules,
-indicate so in your remarks.md file. You MUST try to justify, plead, beg,
-why you consider your rule abuse to be allowed under the
-Rules. Humor or creativity help plead a case.
As there is no guarantee that you will succeed, you might consider submitting an -alternate version that conforms to the Rules, if it might -otherwise be interesting; one that does not abuse the Rules -and one that does, making sure to note in the one that does not abuse the rules -that this is another version, so that the Judges do not assume you uploaded it -by mistake.
+Legal rule abuse may involve, but is not limited to, doing things that +are technically allowed by the Rules and yet do not fit +the spirit of what we intended to be submitted.
+Legal abuse of the Rules is NOT an invitation to +violate the Rules (especially Rule 17 - Use +mkiocccentry). A submission that +violates the rules in the opinion of the +Judges, WILL be disqualified. RULE ABUSE +CARRIES A CERTAIN LEVEL OF RISK!
+If you intend to abuse the Rules, indicate so in your
+remarks.md file. You MUST try to justify, plead, beg, why you
+consider your rule abuse to be allowed under the Rules.
+Humor or creativity help plead a case.
As there is no guarantee that you will succeed, you might consider +submitting an alternate version that conforms to the +Rules, if it might otherwise be interesting; one that +does not abuse the Rules and one that does, making sure +to note in the one that does not abuse the rules that this is another +version, so that the Judges do not assume you uploaded it by mistake.
If you do bypass the mkiocccentry(1) warnings about
Rule 2a - Gross Size
and/or about
Rule 2b - Net Size
-or any other
-rule and submit a submission anyway, you MUST try to justify why the
+or any other
+rule and submit it anyway, you MUST try to justify why the
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 so as not to be overlooked.
We are often asked why the contest Rules and 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.
+violation, and you would be wise to do this towards the top of your +remarks.md file so as not to be overlooked.
+We are often asked why the contest Rules and +Guidelines seem strange or contain mistakes, flaws, +or grammatical errors. One reason is that we sometimes make genuine +mistakes, but in many cases such problems, flaws or areas of confusion +are deliberate.
Changes to Rules and Guidelines in response to rule abuses, are done in a minimal fashion. Often we will -deliberately leave behind holes (or introduce new ones) so that future rule -abuse can continue. A clever author should be able to read and “drive a -truck through the holes” in the Rules and Guidelines.
-At the risk of stating the obvious, this contest is a parody of the software -development process. The Rules and Guidelines -are only part of the overall contest. Even so, one might think the -contest Rules and Guidelines process as a parody -of the sometimes tragic mismatch between what a customer (or marketing) wants -and what engineering delivers. Real programmers must face obfuscated and -sometimes conflicting, ballooning specifications, and requirements from marketing, sales, -product management and even from customers themselves on an all too regular basis. -This is one of the reasons why the Rules and -Guidelines are written in obfuscated form.
+deliberately leave behind holes (or introduce new ones) so that future +rule abuse can continue. A clever author should be able to read and +“drive a truck through the holes” in the Rules and +Guidelines. +At the risk of stating the obvious, this contest is a parody of the +software development process. The Rules and +Guidelines are only part of the overall contest. +Even so, one might think the contest Rules and +Guidelines process as a parody of the sometimes +tragic mismatch between what a customer (or marketing) wants and what +engineering delivers. Real programmers must face obfuscated and +sometimes conflicting, ballooning specifications, and requirements from +marketing, sales, product management and even from customers themselves +on an all too regular basis. This is one of the reasons why the +Rules and Guidelines are written in +obfuscated form.
Jump to: top
The IOCCC no longer discourages the use of multibyte UTF-8 characters in C code.
The IOCCC no longer discourages the use of multibyte UTF-8 characters
+in C code.
We DISLIKE C code with trailing control-M’s (\r or \015) that results
-in compilation failures.
We DISLIKE C code with trailing control-M’s (\r or \015) that
+results in compilation failures.
Some non-UNIX/non-Linux tools such as MS Visual C and MS Visual C++ leave trailing control-M’s on lines. Users of such tools should strip -off such control-M’s before submitting their submissions. In some cases -tools have a “Save As” option that will prevent such trailing control-M’s -being added.
+off such control-M’s before submitting their submissions. In some +cases tools have a “Save As” option that will prevent such trailing +control-M’s being added.Jump to: top
Submissions will be judged in an environment that has no IDE. -Any submission that fails to compile/build because it requires -an IDE will be rejected.
-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.
+See the -FAQ on “What are the detailed recommendations for a submission Makefile?”.
+FAQ on “What are the detailed recommendations for a submission +Makefile?”.Jump to: top
See the
-FAQ on “What should I do with the try.sh and try.alt.sh scripts?”.
try.sh and try.alt.sh
+scripts?”.
See the
FAQ on “What is a .auth.json file?”.
See the
FAQ on “What is a .info.json file?”.
See the -FAQ on “How can I validate my submission directory?”.
+FAQ on “How can I validate my submission +directory?”.See the -FAQ on “What permissions may my files be and what if I need different permissions?”.
+FAQ on “What permissions may my files be and what if I need different +permissions?”.See the -FAQ on “What are the detailed recommendations for a submission Makefile?”.
+FAQ on “What are the detailed recommendations for a submission +Makefile?”.See the -FAQ on “What are the details behind Rule 17 - Use mkiocccentry?”.
+FAQ on “What are the details behind Rule 17 - Use +mkiocccentry?”.Jump to: top
These Guidelines are hints and suggestions, NOT Rules.
-While submissions that violate the Guidelines are allowed, -submissions that remain within the Guidelines are preferred.
+These Guidelines are hints and suggestions, +NOT Rules.
+While submissions that violate the Guidelines are +allowed, submissions that remain within the +Guidelines are preferred.
You are encouraged to review the following FAQs:
Obtaining and compiling the most recent mkiocccentry toolkit
Obtaining and compiling the most recent mkiocccentry +toolkit
While the contest is open, you may modify your previously uploaded submission by rebuilding your submission with the -mkiocccentry toolkit, -and then re-uploading it to the same slot number on the -submit server.
+mkiocccentry toolkit, and +then re-uploading it to the same slot number on the submit +server. -You are encouraged to examine the winners of previous contests.
-Because the Rules change from year to year, some past winning entries -may be rejected this year. What was was unique and novel one year might be ‘old’ the next year.
-A submission is usually examined in a number of ways. We typically apply -a number of tests to a submission:
+You are encouraged to examine the winners of previous +contests.
+Because the Rules change from year to year, some past +winning entries may be rejected this year. What was +was unique and novel one year might be ‘old’ the next year.
+A submission is usually examined in a number of ways. We typically +apply a number of tests to a submission:
#include linesYou should consider how your submission looks in each of the above tests. -You should ask yourself if your submission remains obscure after it has been -‘cleaned up’ by the C pre-processor and a C beautifier.
-Your submission need not pass all of the above tests as in certain cases, -a test is not important.
-Submissions that compete for the -‘strangest/most creative source layout’ need not do as well as -others in terms of their algorithm.
+You should consider how your submission looks in each of the above +tests. You should ask yourself if your submission remains obscure +after it has been ‘cleaned up’ by the C pre-processor and a C +beautifier.
+Your submission need not pass all of the above tests as in certain +cases, a test is not important.
+Submissions that compete for the ‘strangest/most creative source +layout’ need not do as well as others in terms of their algorithm.
Given two submissions, we are more inclined to pick the submission that does something interesting when it’s executed.
-IMPORTANT: Be sure that your submission works as documented in your remarks.md file.
We sometimes make an effort to debug a submission -that has a slight problem, particularly in or near the final round. -On the other hand, we have seen some otherwise excellent submissions -fall down because they didn’t work as documented.
-If you submission has bugs and/or mis-features, you are MUCH 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:
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 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
-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.
Sometimes a strange bug or (mis-)feature can even help the submission! +Of course, a correctly working submission might be better.
+We tend to look down on a prime
+number printer that claims
+that 16 is a prime number. Clever people will note that 16 might be
+prime under certain conditions. ;-) Wise people, when submitting
+something clever will fully explain such cleverness in their
+submission’s remarks.md file.
People who are considering to just use some complex mathematical function or state machine to spell out something such as “hello, -world!” really really, and we do mean REALLY, do need to be more creative.
+world!” really really, and we do mean REALLY, do need to be more +creative.Consider using misleading or subtle tricks layered on top of or under an appropriate level of obfuscation.
-A clean looking program with misleading comments and variable names might be a -VERY GOOD START to a great submission!
+A clean looking program with misleading comments and variable names +might be a VERY GOOD START to a great submission!
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,
-renamed as Makefile of course. This makes it easier for the Judges
-to test your submission. And if your submissions wins, it makes it easier to integrate it into
-the Official IOCCC winner website.
We VERY MUCH LIKE submissions that have some educational value. This does NOT mean
-that your submission should not be obfuscated but rather that the IOCCC has moved away from
-the idea of “spoilers”. You should not encrypt or rot13 content in your remarks.md file.
The above statement does not mean encryption/decryption tools will not win, nor
-does it mean that if you have such a submission that you could not encrypt some
-remarks (such as obfuscation details), but if you do so please put them in a
-separate file and indicate how to undo it. Please do NOT use any cipher to
-encrypt your remarks.md.
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):
Makefile, as described and linked to in the
+FAQ on “What are the detailed recommendations for a submission
+Makefile?,
+renamed as Makefile of course.
+This makes it easier for the Judges to test your +submission. And if your submissions wins, it makes it easier to +integrate it into the Official IOCCC winner +website.
+We VERY MUCH LIKE submissions that have some educational value.
+This does NOT mean that your submission should not be obfuscated
+but rather that the IOCCC has moved away from the idea of “spoilers”.
+You should not encrypt or rot13 content in your remarks.md file.
The above statement does not mean encryption/decryption tools will not
+win, nor does it mean that if you have such a submission that you could
+not encrypt some remarks (such as obfuscation details), but if you do
+so please put them in a separate file and indicate how to decipher it.
+Please do NOT use any cipher to encrypt your remarks.md.
It is VERY MUCH appreciated if your remarks or prog.c have some
+educational value. And although educational value is not required, it
+is an EXCELLENT bonus.
We LIKE submissions that use an edited version of the try.sh
+example script (and if you have alternate code, the same applies with
+the try.alt.sh script):
Of course, it is quite possible that only one invocation is -possible, so it is not necessarily detrimental to your submission if you do not -include one, though we do like interesting and creative uses of submissions. See -also the -FAQ on “submitting try.sh and try.alt.sh scripts”.
+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”.
Jump to: top
Doing masses of #defines to obscure the source has become ‘old’. We
tend to ‘see thru’ masses of #defines due to our pre-processor tests
-that we apply. Simply abusing #defines or -Dfoo=bar won’t go as far
-as a program that is more well rounded in confusion.
#defines or -Dfoo=bar won’t go as
+far as a program that is more well rounded in confusion.
Many C compilers DISLIKE the following code, and so do we:
#define d define
#d foo /* <-- don't expect this to turn into #define foo */In other words, it is a compilation error, and in order to get older -IOCCC winning entries that did this to compile, we had to update them to not do this.
+IOCCC winning entries that did this to compile, we had to update them +to not do this.When declaring local or global variables, you should declare the type:
int this_is_fine;and NOT like this:
this_is_not; /* <-- Try to avoid implicit type declarations */We really DISLIKE submissions that make blatant use of #include of
-large data files to get around the source code size limit. This does not mean
-#include of standard header files, just data files you provide.
On 28 January 2007, the Judges rescinded the requirement that the
-# in a C preprocessor directive must be the 1st non-whitespace byte.
We really DISLIKE submissions that make blatant use of #include
+of large data files to get around the source code size limit. This does
+not mean #include of standard header files, just data files you
+provide.
On 28 January 2007, the Judges rescinded the requirement that the #
+in a C preprocessor directive must be the 1st non-whitespace byte.
We tend to like less a submission that requires either
-gcc OR clang. We prefer submissions that can compile
-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.
We tend to like less a submission that requires either gcc
+OR clang. We prefer submissions that can compile 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:
+One side effect of the above is that you cannot assume the use of +nested functions such as:
int main() {
| void please_dont_submit_this() {
| printf("The machine that goes BING!!\n");
}
| please_dont_submit_this();
}On 2012 July 20, the Judges rescinded the encouragement of
-nested functions. Such constructions, while interesting and sometimes
-amusing, will have to wait until they are required by a C standard that are
-actually implemented in BOTH gcc AND clang.
We DISLIKE submissions that require the use of -fnested-functions.
On 2012 July 20, the Judges rescinded the
+encouragement of nested functions. Such constructions, while
+interesting and sometimes amusing, will have to wait until they are
+required by a C standard that are actually implemented in BOTH
+gcc AND clang.
We DISLIKE submissions that require the use of
+-fnested-functions.
If your submission uses functions that have a variable number of
-arguments, be careful. Systems implement va_list in a wide variety
-of ways. Because of this, a number of operations using va_list are
-not portable and must not be used:
va_list in a wide
+variety of ways. Because of this, a number of operations using
+va_list are not portable and must not be used:
va_list variable to/from a va_list variableva_list variable into/from a va_list variableIn 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.
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.
exit(3)The exit(3) function returns void. Some broken systems have exit(3)
-return int; your submission should assume that exit(3) returns a void.
The exit(3) function returns void. Some broken systems have
+exit(3) return int; your submission should assume that exit(3)
+returns a void.
Small programs are best when they are short, obscure and concise. -While such programs are not as complex as other winners, they do -serve a useful purpose: they are often the only program that people -attempt to completely understand. For this reason, we look for -programs that are compact, and are instructional.
-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.
+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.We suggest that you avoid trying for the ‘smallest self-replicating’ source. The smallest, a zero byte entry, won in 1994.
-Programs that claim to be the smallest C source that does something, really +
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. +Programs that claim to be the smallest C source that does something, really better be the smallest such program or they risk being rejected because they do not work as documented.
+We want to get away from source that is simply a compact blob of bytes. REALLY TRY to be more creative than blob coding. HINT!
Unless you are cramped for space, or unless you are entering the ‘Best one liner’ category, we suggest that you format your program in a more creative way than simply forming excessively long lines.
-The Makefile should not be used to try and get around the size limit. It is
-one thing to make use of a several -Ds on the compile line to help out, but it
-is quite another to use many bytes of -Ds in order to try and squeeze the
-source under the size limit.
Please do not use things like gzip(1) to get around the size limit. This was
-done years ago; please try to be much more creative.
The Makefile should not be used to try and get around the size limit.
+It is one thing to make use of a several -Ds on the compile line to
+help out, but it is quite another to use many bytes of -Ds in order
+to try and squeeze the source under the size limit.
Please do not use things like gzip(1) to get around the size limit.
+This was done years ago; please try to be much more creative.
Your source code, post-pre-processing, should not exceed the size of -Microsoft Windows. :-)
+Microsoft Windows. +:-)We tend to DISLIKE programs that:
index(3)/strchr(3) differences are OK, but
-sockets/streams specific code is likely not to be)index(3)/strchr(3) differences are
+OK, but sockets/streams specific code is likely not to be)remarks.md file)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 +
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 Specification @@ -1100,156 +1183,163 @@
#include <windows.h> /* we DISLIKE this */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 +
You may compile and use your own programs. If you do, try to build and +execute from the current directory. This restriction is not a hard and absolute one. The intent is to ensure that the building of your program is reasonably portable.
We prefer programs that are portable across a wide variety of UNIX-like operating systems (e.g., Linux, GNU Hurd, BSD, UNIX, macOS, etc.).
-Try to avoid submissions that play music that some people believe is copyrighted -music.
-Did we remember to indicate that programs that blatantly use -some complex state machine to do something simple, are boring? -We think we did. :-)
-Given two versions of the same program, one that is a compact blob -of code, and the other that is formatted more like a typical C -program, we tend to favor the second version. Of course, a third -version of the same program that is formatted in an interesting -and/or obfuscated way, would definitely win over the first two! -Remember, you can submit more than one submission. See the -Rules -for details (in particular, -Rule 8 - Submitting requirements).
-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:
+Try to avoid submissions that play music that some people believe is +copyrighted music.
+Did we remember to indicate that programs that blatantly use some +complex state machine to do something simple, are boring? We think we +did. :-)
+Given two versions of the same program, one that is a compact blob of +code, and the other that is formatted more like a typical C program, we +tend to favor the second version. Of course, a third version of the +same program that is formatted in an interesting and/or obfuscated way, +would definitely win over the first two!
+Remember, you can submit more than one submission. See the +Rules for details (in particular, Rule 8 - Submitting +requirements).
+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
-Makefile, described in the Makefile section), do not assume this
-sort of code will work:
char *T = "So many primes, so little time!";
...
T[14] = ';'; /* modifying a string requires: -fwritable-strings */Even so, one should probably not assume that this is universally accepted.
-Initialized char arrays are OK to write over. For instance, this is OK:
+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 */We prefer code that can run on either a 64-bit or 32-bit -processor. However, it is UNWISE to assume it will run on an -some Intel-like x86 architecture**.
-While programs that only run in a specific word size are OK, if you have -to pick, choose a 64-bit word size.
-If your submission MUST run only on a 64-bit or 32-bit architecture,
-then you MUST specify the -arch on your command line
-(see ARCH in the example
-Makefile, described in Makefile section). Do not assume a
-processor word size without specifying -arch. For example:
We prefer code that can run on either a 64-bit or 32-bit processor. +However, it is UNWISE to assume it will run on an some Intel-like +x86 architecture**.
+While programs that only run in a specific word size are OK, if you +have to pick, choose a 64-bit word size.
+If your submission MUST run only on a 64-bit or 32-bit
+architecture, then you MUST specify the -arch on your command
+line (see ARCH in the example Makefile, described in the FAQ on
+“What are the detailed recommendations for a submission
+Makefile?.
Do not assume a processor word size without specifying -arch. For
+example:
ARCH= -m64Note, however, that some platforms will not necessarily support some
-architectures. For instance, more recent versions of macOS do NOT support
-32-bit, and more than zero Judges use it!
macOS do NOT
+support 32-bit, and more than zero Judges use it!
X client submissions should be as portable as possible. Submissions that -adapt to a wide collection of environments will be favored. For -example, don’t depend on a particular type or size of display. -Don’t assume the use of a particular browser. Instead assume a -generic browser that forms to a widely used W3C standard. -Don’t assume a particular sound sub-system or video driver is installed -in the OS. Instead, make use of a well known and widely available open -source program (one that actually works) to display audio/visual data.
+X client submissions should be as portable as possible. Submissions +that adapt to a wide collection of environments will be favored. For +example, don’t depend on a particular type or size of display. Don’t +assume the use of a particular browser. Instead assume a generic +browser that forms to a widely used W3C +standard. Don’t assume a particular +sound sub-system or video driver is installed in the OS. Instead, make +use of a well known and widely available open source program (one that +actually works) to display audio/visual data.
X client submissions should avoid using X related libraries and software that are not in wide spread use.
-As of Red Hat RHEL9.0, the X.org server is deprecated. See the -FAQ on “Xorg deprecation”” -for more details. This does not mean that a submission using this will -necessarily be rejected, but it would be better if it can support Wayland in -some way or another.
-We DISLIKE submissions that use proprietary toolkits such as 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.
As of Red Hat RHEL9.0, the X.org server is deprecated. See the FAQ on +“Xorg deprecation”” for more details. +This does not mean that a submission using this will necessarily be +rejected, but it would be better if it can support Wayland in some way +or another.
+We DISLIKE submissions that use proprietary toolkits such as 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.
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
+.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.
One should restrict libcurses to portable features found on both BSD and Linux curses.
Jump to: top
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 +
We DISLIKE the use of ASCII tab characters in markdown files, such
+as in the required remarks.md file.
We don’t mind the use of ASCII tab characters in your C code. Feel +free to use ASCII tab characters if that suits your obfuscation needs. +If is perfectly OK to use tab characters elsewhere in your +submission, just not in markdown files as this tends annoy us when it +comes time to rendering your markdown content as it complicates the +process.
+If you do use ASCII tab characters in your non-markdown files, be aware +that some people may use a tab stop that is different than the common 8 character tab stop.
-PLEASE observe our Markdown Guidelines
-when forming your submission’s remarks.md file. And if your submission
-contains additional markdown files, please follow those same Guidelines for
-those files. See also
-Rule 4 - Required files,
-and the
-FAQ on “markdown”.
PLEASE observe our Markdown Guidelines when
+forming your submission’s remarks.md file. And if your submission
+contains additional markdown files, please follow those same Guidelines
+for those files.
See also Rule 4 - Required files, +and the FAQ on “markdown”.
Jump to: top
You are better off explaining what your submission does in your
remarks.md file section rather than leaving it obscure for the
-Judges as we might miss something and/or be too tired to
-notice.
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
+Judges as we might miss something and/or be too tired
+to notice.
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.
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 -such that at first glance (if you squint and don’t look at the details) -the code might pass for non-obfuscated C. Deceptive comments, -and misleading formatting, in some cases, may be a plus. On the -other hand, a misleading code style requires more source bytes.
-If you do elect to use misleading formatting and comments, we
-suggest you remark on this point in your remarks.md where you talk
-about why you think your submission is obfuscated. 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!
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:
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) the +code might pass for non-obfuscated C. Deceptive comments, and +misleading formatting, in some cases, may be a plus. On the other +hand, a misleading code style requires more source bytes.
+If you do elect to use misleading formatting and comments, we suggest
+you remark on this point in your remarks.md where you talk about why
+you think your submission is obfuscated. 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 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. :-)
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
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
+ While we recognize that UNIX is not a universal operating system, the
+contest does have a bias towards such systems. In an effort to expand
+the scope of the contest, we phrase our bias to favor the Single UNIX
Specification
(UNIX-like). You are well advised to submit code that conforms to the Single UNIX
-Specification Version 4. You are well advised to submit code that conforms to the Single
+UNIX Specification Version 4. To quote the Judges: We LIKE programs that: Some types of programs can’t excel (anti-tm) in some areas. Your
program doesn’t have to excel in all areas, but doing well in several
areas really does help. If there are limitations in your submission, you are highly encouraged
+to note such limitations in your This submission factors values up This submission factors values up
+ The Judges might try to factor the value -5, so you want to might state: The Judges might try to factor the value -5, so you
+want to might state: This submission factors positive values up
-
@@ -1264,66 +1354,83 @@
Miscellaneous
remarks.md file. For example if
+your submission factors values up to a certain size, you might want to
+state:
-
-2305567963945518424753102147331756070.
-Attempting to factor larger values will produce unpredictable results.2305567963945518424753102147331756070. Attempting to factor larger
+values will produce unpredictable results.
2305567963945518424753102147331756070. Attempting to factor large values will
-produce unpredictable results.2305567963945518424753102147331756070. Attempting to factor large
+values will produce unpredictable results.
However the Judges might try to also factor 0, so you might want to state:
+However the Judges might try to also factor 0, so you +might want to state:
-This submission factors values between 1 and -
+2305567963945518424753102147331756070. Attempting to factor values outside -that range will 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 -will produce unpredictable results.2305567963945518424753102147331756070. Attempting to factor anything +else will produce unpredictable results.
You submission might be better off catching the attempt to factor bogus values -and doing something interesting. So you might want to code accordingly and state:
+You submission might be better off catching the attempt to factor bogus +values and doing something interesting. So you might want to code +accordingly and state:
--This submission factors integers between 1 and
+2305567963945518424753102147331756070. -Attempting to factor anything else will cause the program to insult your pet fish Eric.This submission factors integers between 1 and +
2305567963945518424753102147331756070. Attempting to factor anything +else will cause the program to insult your pet fish Eric.
The Judges might not have a pet fish named Eric, so you might want to state:
+The Judges might not have a pet fish named Eric, so +you might want to state:
-This submission factors integers between 1 and -
+2305567963945518424753102147331756070. Attempting to factor anything else -will cause the program to insult your pet fish Eric, or in the case that you -lack such a pet, will insult the pet that you do not have.2305567963945518424753102147331756070. Attempting to factor anything +else will cause the program to insult your pet fish Eric, or in the +case that you lack such a pet, will insult the pet that you do not +have.
When all other things are equal, a submission with fewer limitations will be judged -better than a submission with lots of limitations. So you might want to code accordingly -and state:
+When all other things are equal, a submission with fewer limitations +will be judged better than a submission with lots of limitations. So +you might want to code accordingly and state:
-+This submission attempts to a factor value of any size provided that the -program is given enough time and memory. If the value is not a proper integer, -the program might insult a fish named Eric.
+This submission attempts to a factor value of any size provided +that the program is given enough time and memory. If the value is not +a proper integer, the program might insult a fish named Eric.
Do not fear if you’re not 100% sure of the significance of
+2305567963945518424753102147331756070 as it is not of prime
+importance: or is it? :-)
Jump to: top
The IOCCC submit server, and related services -use the most recent version of the -mkiocccentry toolkit: -submissions that package using older versions of the -mkiocccentry toolkit -are LIKELY to be REJECTED!
+The IOCCC submit server, and related +services use the most recent version of the mkiocccentry +toolkit: submissions that +package using older versions of the mkiocccentry +toolkit are LIKELY to +be REJECTED!
You REALLY SHOULD use the latest mkiocccentry -toolkit to package your submission -as submissions that use an older version are LIKELY to be REJECTED!
+toolkit to package your +submission as submissions that use an older version are WILL +be REJECTED!The mkiocccentry(1) tool runs a number of checks by way of these
-mkiocccentry toolkit tools:
Do NOT use txzchk(1) or fnamchk(1) command line options that are labeled
-“for TESTING purposes” in their respective man pages.
Do NOT use fnamchk(1) command line options that are labeled “for TESTING purposes”
-in the fnamchk(1) man page.
Do NOT use chksubmit(1) command line options that are labeled “for the use by the Judges only”
-in the chksubmit(1) man page.
-Similarly do NOT use chkentry(1) command line options marked “for the use
-by the Judges only” in the chkentry(1) man page.
To view mkiocccentry toolkit man pages, -while your current directory is the top of the source tree:
+Do NOT use txzchk(1) or fnamchk(1) command line options that
+are labelled “for TESTING purposes” in their respective man pages.
Do NOT use fnamchk(1) command line options that are labelled
+“for TESTING purposes” in the fnamchk(1) man page.
Do NOT use chksubmit(1) command line options that are labelled
+“for the use by the Judges only” in the chksubmit(1) man page.
Similarly do NOT use chkentry(1) command line options marked
+“for the use by the Judges only” in the chkentry(1) man page.
To view mkiocccentry +toolkit man pages, while +your current directory is the top of the source tree:
man soup/man/man1/mkiocccentry.1
man soup/man/man1/iocccsize.1
man soup/man/man1/txzchk.1
man test_ioccc/man/man1/fnamchk.1
man soup/man/man1/chksubmit.1
man soup/man/man1/chkentry.1The above man(1) commands will show the toolkit man pages without having to install them first.
So that you do not have to repeatedly answer all the mkiocccentry(1) questions,
-use mkiocccentry -a answers ... to create a file containing the answers you first give,
-so later enter mkiocccentry -i answers ... to reuse those same answers.
The mkiocccentry -A answers ... does the same thing except that the answers file will be overwritten.
The mkiocccentry -i answers ... will still be required to confirm “Yes/No” questions.
Use mkiocccentry -Y -i answers .. to force a yes answers with great caution
-because it might force a yes answer to something you do NOT want, such as a
-change in your code that violates a detected rule.
-The mkiocccentry -i answers .. will still be required to confirm “Yes/No” questions.
-While mkiocccentry -Y -i answers .. will force yes answers, use with great caution,
-because it might force a yes answer to something you do NOT want.
To help with not having to repeatedly enter a UUID, put your UUID into a file and use
-mkiocccentry -u uuidfile ..., or use mkiocccentry -U UUID ... to give the UUID
-on the command line.
If you wish to test that your submission passes the mkiocccentry(1) tests
-without having to type in 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:
The above man(1) commands will show the toolkit man pages without
+having to install them first.
So that you do not have to repeatedly answer all the mkiocccentry(1)
+questions, use mkiocccentry -a answers ... to create a file
+containing the answers you first give, so later enter mkiocccentry -i answers ... to reuse those same answers.
The mkiocccentry -A answers ... does the same thing except that the
+answers file will be overwritten.
The mkiocccentry -i answers ... will still be required to confirm
+“Yes/No” questions.
Use mkiocccentry -Y -i answers .. to force a yes answers with great
+caution because it might force a yes answer to something you do
+NOT want, such as a change in your code that violates a detected
+rule.
The mkiocccentry -i answers .. will still be required to confirm
+“Yes/No” questions. While mkiocccentry -Y -i answers .. will force
+yes answers, use with great caution, because it might force a yes
+answer to something you do NOT want.
To help with not having to repeatedly enter a UUID, put your UUID into
+a file and use mkiocccentry -u uuidfile ..., or use mkiocccentry -U UUID ... to give the UUID on the command line.
If you wish to test that your submission passes the
+mkiocccentry(1) tests without having to type in 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 cd workdir/UUID-slot_num && tar --format=v7 -cJf submit.UUID-slot_num.timestamp.txz UUID-slot_numIn many places the mkiocccentry(1) tool will prompt you to verify what you input, allowing you to
-correct details as you go along.
In many places the mkiocccentry(1) tool will prompt you to verify
+what you input, allowing you to correct details as you go along.
The mkiocccentry(1) tool will use code from iocccsize(1) which detects a number of
-issues (such as Rule 2 - Size restrictions) that you may ignore,
-however ignoring such issues comes with a SIGNIFICANT level of risk!
Once the tarball is packaged it will
-run txzchk(1), which will also run fnamchk(1), as part of its algorithm.
The mkiocccentry(1) tool will use code from iocccsize(1) which
+detects a number of issues (such as Rule 2 - Size
+restrictions) that you may ignore, however
+ignoring such issues comes with a SIGNIFICANT level of risk!
Once the tarball is packaged it will run txzchk(1), which will also
+run fnamchk(1), as part of its algorithm.
If mkiocccentry encounters an error, the program will exit and the xz
-compressed tarball will NOT be generated: this is a feature, not a bug!
If you encounter a bug with the
-mkiocccentry toolkit
-PLEASE run the bug_report.sh script to help us out here!
If mkiocccentry encounters an error, the program will exit and
+the xz compressed tarball will NOT be generated: this is a
+feature, not a bug!
If you encounter a bug with the mkiocccentry
+toolkit PLEASE run the
+bug_report.sh script to help us out here!
mkiocccentry(1) tool to abort with a fatal error.
See
-FAQ on “How do I report bugs in an mkiocccentry tool?”.
See Rule 11 - Legal rule abuse for warnings about ignoring mkiocccentry(1) tool warnings.
See +
See the
+FAQ on “How do I report bugs in an mkiocccentry
+tool?”.
See Rule 11 - Legal rule abuse
+for warnings about ignoring mkiocccentry(1) tool warnings.
See the
FAQ on “What is the fnamchk tool?”.
See -FAQ on “What is mkiocccentry in simple terms?”.
-See -FAQ on “What is the mkiocccentry tool, how do I obtain it and how do I use it”.
+See the +FAQ on “What is mkiocccentry in simple +terms?”.
+See the +FAQ on “What is the mkiocccentry tool, how do I obtain it and how do I +use it”.
Jump to: top
The reason for the times of day are so that key IOCCC events are calculated -to be a functional UTC time. :-)
-At least 2 of several reasons for selecting the prime, 2503, for -Rule 2b - Net Size -may be found on the “Curios!” about 2503.
-The 2503 value for Rule 2b - Net Size is a decimal anagram -of the number of the kernel disk pack of one of the judge’s BESM-6.
+The reason for the times of day are so that key IOCCC events are +calculated to be a functional UTC time. :-)
+At least 2 of several reasons for selecting the prime, 2503, for Rule +2b - Net Size may be found on the +“Curios!” about 2503.
+The 2503 value for Rule 2b - Net Size is +a decimal anagram of the number of the kernel disk pack of one of the +judge’s BESM-6.
-Some people might question what actually constitutes a valid JSON file, given -the state of the “so-called” JSON spec. :-)
-We prefer programs that do not require a fish license: crayons and -cat detector vans not withstanding.
+Some people might question what actually constitutes a valid JSON file, +given the state of the “so-called” JSON spec. :-)
+We prefer programs that do not require a fish license: crayons and cat +detector vans not withstanding.
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 +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.
At least one judge prefers to maintain the use of the -leap-second -as part of the world’s time standard. If your code prints time -with seconds, we prefer that your code be capable of printing the -time of day during a leap-second where the value in seconds -after the minute mark is 60.
+leap-second as part of the +world’s time standard. If your code prints time with seconds, we +prefer that your code be capable of printing the time of day during a +leap-second where the value in seconds after the minute mark is 60.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 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. :-) -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 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. :-)
+marks the spot”. Yet on the third hand, windows are best when they +are “unseen” (i.e., not dirty). :-) +The Judges, as a group, have a history giving wide +degree of latitude to reasonable submissions. And recently they have +had as much longitudinal variation as it is possible to have on +Earth. :-) 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 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 are in a maze of twisty guidelines, all different.
There are at least zero Judges who think that -Fideism has little -or nothing to do with the Judging process.
+Fideism has little or nothing +to do with the Judging process.@@ -1552,25 +1677,29 @@All generalizations are false, including this one. – Mark Twain
This could be the only guideline that contains the word fizzbin.
-However, do you know how to play fizzbin? +
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. :-)
-NOTE: The previous guideline in this spot has been replaced by this guideline:
+NOTE: The previous guideline in this spot has been replaced by +this guideline:
Any complaints about the above guideline could be addressed to the Speaker of the House of Commons, or to the speaker of your national parliament should you have one.
We believe that Mark Twain’s quote:
@@ -1578,31 +1707,37 @@Fun😄damental Guidelines
… is a good motto for those writing code for the IOCCC.
+ + -Do not fear if you’re not 100% sure of the significance of
-2305567963945518424753102147331756070 as it is not of prime importance: or is
-it? :-)
See the Official IOCCC website news for additional information.
-For questions or comments about the contest, see Contacting the IOCCC.
-Be SURE to review the current IOCCC Rules and Guidelines as they -often change year to year. Especially prior to submitting to the contest.
-For the latest IOCCC news, follow the IOCCC on Mastodon. See our -FAQ on “Mastodon” -for more information.
-Also consider joining the IOCCC Discord Server
-for the latest news, discussions about The Rules, questions for the Judges, and C in general.
See the Official IOCCC website news for additional +information.
+For questions or comments about the contest, see Contacting the +IOCCC.
+Be SURE to review the current IOCCC Rules and +Guidelines as they often change year to year. Especially +prior to submitting to the contest.
+For the latest IOCCC news, follow the IOCCC on +Mastodon. See our FAQ on +“Mastodon” for more information.
+Also consider joining the IOCCC Discord
+Server for the latest news,
+discussions about The Rules, questions for the Judges, and C in
+general.
Jump to: top
diff --git a/next/guidelines.md b/next/guidelines.md index ae8daf1b65..e9e53ecef8 100644 --- a/next/guidelines.md +++ b/next/guidelines.md @@ -4,24 +4,26 @@ Copyright © 2025 Leonid A. Broukhis and Landon Curt Noll. -All Rights Reserved. Permission for personal, education or non-profit use is -granted provided this copyright and notice are included in its entirety -and remains unaltered. All other uses must receive prior permission in -writing by [contacting the Judges](../contact.html). +All Rights Reserved. Permission for personal, education or non-profit +use is granted provided this copyright and notice are included in its +entirety and remains unaltered. All other uses must receive prior +permission in writing by [contacting the Judges](../contact.html). # Guidelines Version Be sure to read the [Rules](rules.html). @@ -34,39 +36,44 @@ Be sure to read the [Rules](rules.html).The IOCCC is NOT accepting new submissions at this time. See the -IOCCC winning entries page for the entries that have won the -IOCCC in the past.
-These rules are a TENTATIVE proposal for the next IOCCC -and are likely be to be updated before the next IOCCC.
+IOCCC winning entries page for the entries that have +won the IOCCC in the past. +These rules are a TENTATIVE proposal for the next IOCCC and are +likely be to be updated before the next IOCCC.
See our FAQ on “rules, guidelines, tools feedback” as well as our FAQ on “about asking questions” -about these rules. You might also find the FAQ in general useful, especially the +about these rules. You might also find the FAQ in general useful, +especially the FAQ on “how to enter the IOCCC”.
-Watch both the IOCCC status page and the -@IOCCC mastodon feed for information about +
Watch both the IOCCC status page and the @IOCCC +mastodon feed for information about future IOCCC openings.
HINT to mastodon users: You may wish to refresh the @IOCCC -mastodon feed page and/or mastodon -app from time to time to view IOCCC mastodon updates.
+mastodon feed page and/or mastodon app +from time to time to view IOCCC mastodon updates.These IOCCC Rules are version 29.13 2025-12-01.
+These IOCCC Rules are version 29.14 2025-12-02.
Reminder: be SURE to read the IOCCC guidelines.
2025-12-03 20:25:12.045045 UTC to 2026-03-13 17:19:23.293137 UTC.
-The above dates and times may change AT ANY TIME until the contest status is open.
+The above dates and times may change AT ANY TIME until the +contest status is open.
-See Entering the IOCCC: the bare minimum you need to know.
+See Entering the IOCCC: the bare minimum you need to +know.
See -FAQ on “How can I comment or make a suggestion on IOCCC rules, guidelines and tools?”.
+FAQ on “How can I comment or make a suggestion on IOCCC rules, +guidelines and tools?”.See the Guidelines for Rule 1 - C program.
+See the Guidelines for Rule 1 - C +program.
Rule 2 requires that your submission satisfy BOTH
-Rule 2a (Gross Size)
-and
-Rule 2b (Net Size).
-During development this can be checked using iocccsize(1):
Rule 2 requires that your submission satisfy BOTH Rule 2a
+(Gross Size) and Rule 2b (Net
+Size).
During development this can be checked using iocccsize(1):
iocccsize prog.cSee the Guidelines for Rule 2 - Size restrictions.
+See the Guidelines for Rule 2 - Size +restrictions.
The overall maximum size of your prog.c program source MUST NOT
exceed 4993 bytes.
See Entering the IOCCC: the bare minimum you need to know.
+See Entering the IOCCC: the bare minimum you need to +know.
When the filename of your program source (i.e., prog.c) 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 MUST
-NOT exceed 2503.
NOTE: iocccsize does NOT calculate the filename length.
Check your source code using the latest official IOCCC size tool,
+iocccsize(1). The value printed MUST NOT exceed 2503.
See Rule 17 - Use mkiocccentry.
You MUST register, using a valid email address, in order to submit -to the IOCCC. You may register while the contest is pending or open.
+to the IOCCC. You may register while the contest is pending or +open.A few days after registering, you’ll receive your UUID username and temporary password, which you MUST change within 14 days.
See How to register for the IOCCC.
-See Entering the IOCCC: the bare minimum you need to know.
-See Guidelines for Rule 3 - Register for the IOCCC.
+See Entering the IOCCC: the bare minimum you need to +know.
+See Guidelines for Rule 3 - Register for the +IOCCC.
|
-* .info.json and .auth.json MUST be generated by mkiocccenty(1)
-when packing a submission. When chksubmit(1) is run on the submission
-directory ALL tests must pass and if there is ANY problem with these
-JSON files or if either is missing it will fail. See Rule 17 - use
-mkiocccentry.
.info.json and .auth.json MUST be generated by
+mkiocccenty(1) when packing a submission. When chksubmit(1) is run
+on the submission directory ALL tests must pass and if there is
+ANY problem with these JSON files or if either is missing it will
+fail. See Rule 17 - use mkiocccentry.
|
* The Makefile, remarks.md,.info.json, and .auth.json MUST
-have a file size greater than 0 and MUST have content. Note that
-mkiocccentry(1) will check for file size but will NOT check for
-content.
mkiocccentry(1) will check for file size but will NOT
+check for content.
|
-* Your submitted source code MUST be called prog.c. When the Makefile
-compiles your code, the executable (if applicable) MUST be called prog.
-The Makefile may compile your source code into other filenames as well, if you want.
prog.c. When the
+Makefile compiles your code, the executable (if applicable) MUST
+be called prog. The Makefile may compile your source code into
+other filenames as well, if you want.
|
* As prog, prog.alt, prog.alt.o, prog.o may be created by your
-Makefile, your submission MUST NOT include those files in your top directory.
Makefile, your submission MUST NOT include those files in your
+top directory.
|
* Your submission may NOT have any file that starts with COPYING,
COPYRIGHT, or LICENSE as those files are reserved by IOCCC.
|
-* Your submission may NOT have in the top directory: prog.orig.c,
-README.md or index.html as those files are reserved by the IOCCC.
prog.orig.c, README.md or index.html as those files are reserved
+by the IOCCC.
|
* Your submission may NOT have in the top directory any file
that matches a file glob pattern form [0-9][0-9][0-9][0-9]_*.tar.bz2
as those files are reserved by IOCCC.
| -* Your submission may ONLY contain files and directories. Other file -types such as symlinks, sockets etc. are NOT allowed.
+* Your submission may ONLY contain files and directories. Other +file types such as symlinks, sockets etc. are NOT allowed.|
-* All directories MUST have permission mode of 0755. All files
-MUST have the file mode of 0444, EXCEPT for files that
+* All directories MUST have permission mode of 0755. All
+files MUST have the file mode of 0444, EXCEPT for files that
end in .sh which must have a mode of 0555.
|
* All files that end in .md MUST be in markdown format.
|
-* All filenames are treated as case insensitive. For example, REMARKS.MD,
-and Remarks.md, and remarks.md are considered by mkiocccenty(1)
-to be the SAME file. When preparing a submission on a case
-sensitive filesystem, ensure that the submission will work on
+* All filenames are treated as case insensitive. For example,
+REMARKS.MD, and Remarks.md, and remarks.md are considered by
+mkiocccenty(1) to be the SAME file. When preparing a submission
+on a case sensitive filesystem, ensure that the submission will work on
a case insensitive filesystem.
The remarks.md and Makefile are explained in more detail in the Guidelines.
The remarks.md and Makefile are explained in more detail in the
+Guidelines.
See IOCCC markdown guidelines.
See Rule 17 - Use mkiocccentry.
See the -FAQ on “What permissions may my files be and what if I need different permissions?”.
+FAQ on “What permissions may my files be and what if I need different +permissions?”.See the -FAQ on “What are the detailed recommendations for a submission Makefile?”.
-See the Guidelines on the mkiocccentry toolkit.
+FAQ on “What are the detailed recommendations for a submission +Makefile?”. +See the Guidelines on the mkiocccentry +toolkit.
Your submission MUST NOT modify the filenames or content of any of your
-original submission, such as prog.c, Makefile, or ANY other supplied
-files. To modify files, your program can make a copy or you can use the
-Makefile to setup working copies. Any working copies MUST be cleaned up
-by the Makefile clobber target, so as to restore the directory to its
-original state.
Your submission MUST NOT create or modify directories and files
-ABOVE the current directory (with the exception of the /tmp and the /var/tmp
-directories and as long as the directory name or filename does NOT start
-with a . (dot)).
Your submission MUST NOT modify the filenames or content of any of
+your original submission, such as prog.c, Makefile, or ANY
+other supplied files. To modify files, your program can make a copy or
+you can use the Makefile to setup working copies. Any working copies
+MUST be cleaned up by the Makefile clobber target, so as to
+restore the directory to its original state.
With the exception of the /tmp and the /var/tmp directories,
+assuming the directory name or filename does NOT start with a .
+(dot), your submission MUST NOT create or modify directories and
+files ABOVE the current directory.
The Makefile clobber target MUST restore your submission to its
-original form, including the removal of any created files and directories.
See Rule 16 - Anonymous Judging, and -Guidelines for Rule 7 - Original Work.
+Guidelines for Rule 7 - Original +Work.The submit server will accept submissions ONLY from those who have -registered and ONLY while the contest is open.
-The submit server places a total size limit of 3999971 bytes PER -submission.
- +The submit server places a total size limit of 3999971 bytes +PER submission.
+ + +See Rule 3 - Registering for the IOCCC, Rule 15 - GNU Makefile, and Rule 17 - Use mkiocccentry.
-See Guidelines for Rule 8 - Submitting requirements.
+See Guidelines for Rule 8 - Submitting +requirements.
Entries requiring human interaction to be initially compiled are NOT
-permitted. However, see the guidelines. Each entry MUST automate the
-build process using bash, gmake, gcc and/or clang and other commonly
-available tools under an SUS
+permitted. However, see the guidelines on rule
+9 as you
+may suggest alternative compilation steps to do something fun or
+cute.
Each entry MUST automate the build process using bash, gmake,
+gcc and/or clang and other commonly available tools under an SUS
environment.
NOTE: The references to gmake(1) can be any GNU Make compatible tool.
NOTE: it is better to use the ${MAKE} variable as then one may override
-the make command.
NOTE: it is better and more portable to NOT modify the ${CC} variable
-in the Makefile.
NOTE: any reference to gmake(1) can be any GNU Make compatible
+tool.
NOTE: it is better to use the ${MAKE} variable as then one may
+override the make command.
NOTE: it is better to NOT modify ${CC} in your Makefile as
+this makes your program more portable.
See Guidelines for Rule 9 - No interactive compiling allowed.
+See Guidelines for Rule 9 - No interactive compiling +allowed.
Programs that require special privileges (setuid(2), setgid(2),
-super-user, special owner, special group, etc.) are HIGHLY DISCOURAGED.
-We do NOT guarantee these functions will behave as you expect on our
-test platforms. If your program needs special permissions you MUST
-document this fact and explain why it is needed in your submission’s
-remarks.md file, preferably close to the top.
If your program needs special permissions you MUST document this
+fact and explain why it is needed in your submission’s remarks.md
+file, preferably close to the top, because mkiocccentry(1) will
+NOT set those modes.
Furthermore, if you need a supplementary program that you include to
-have these permissions, you will also have to explain this as well, because these
-bits are NOT allowed in submissions and those bits will NOT be copied by
-mkiocccentry(1).
mkiocccentry(1) either.
See Rule 4 - Required files, and Rule 5 - Do NOT modify files.
@@ -753,95 +790,111 @@Legal abuse of the rules is somewhat encouraged, but comes with risks.
-A submission that, in the opinion of the Judges, violates the rules WILL
-BE DISQUALIFIED. Submissions that plan to abuse the rules MUST justify
-why their rule abuse is legal (or interesting) in the remarks.md file.
Legal abuse of the rules is somewhat encouraged, but comes with
+risks. A submission that, in the opinion of the Judges, violates
+the rules WILL BE DISQUALIFIED. Submissions that plan to abuse the
+rules MUST justify why their rule abuse is legal (or interesting)
+in the remarks.md file.
Submission packaging abuse will NOT be tolerated and for this reason,
-amongst many others, it is recommended that you use mkiocccentry(1). During
-development you can check your prog.c size limits using iocccsize(1), e.g.,
-iocccsize -v1 prog.c. Overriding problems detected by any of the IOCCC tools
-risks that the submission will be rejected.
mkiocccentry(1). See also Rule 17 - use
+mkiocccentry.
+During development you can check your prog.c size limits using
+iocccsize(1), e.g., iocccsize -v1 prog.c. Overriding problems
+detected by any of the IOCCC tools risks that the submission will be
+rejected.
If you do submit a rule abusing or 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 Judges don’t think you uploaded a duplicate into a
-wrong slot by mistake.
See Guidelines for Rule 11 - Legal rule abuse.
+version, PLEASE indicate that in yourremarks.md file of your
+non-rule abusing version so that the Judges don’t think you uploaded a
+duplicate into a wrong slot by mistake.
+See Guidelines for Rule 11 - Legal rule +abuse.
Use of UTF-8 is supported by C89 standard and its updates and so too by the
-IOCCC.
Use of UTF-8 is supported by C89 standard and its updates and so too
+by the IOCCC.
See Guidelines for Rule 12 - UTF-8.
Any C source that fails to compile because lines contain carriage-returns
-(CTRL+M, \r) in particular as part of DOS/Windows style newlines might
-be rejected. Please do NOT put trailing CTRL+M in prog.c, Makefile,
-or remarks.md files, but instead end lines with Unix newline (line-feed,
-CTRL+J, \n).
Any C source that fails to compile because lines contain
+carriage-returns (CTRL+M, \r) in particular as part of DOS/Windows
+style newlines might be rejected. Please do NOT put trailing
+CTRL+M in prog.c, Makefile, or remarks.md files, but instead end
+lines with Unix newline (line-feed, CTRL+J, \n).
You are permitted, in order to try and squeeze your prog.c under a
-Rule 2a Gross Size and/or
-Rule 2b Net Size
-limits, to NOT end source with a newline. 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.
See Guidelines for Rule 13 - No carriage returns in prog.c.
+Rule 2a Gross Size and/or Rule 2b Net +Size limits, to NOT end source with a +newline. 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.
+See Guidelines for Rule 13 - No carriage returns in +prog.c.
Submissions that are substantially similar to previous winning IOCCC -entries are discouraged.
-You are allowed to resubmit to a later contest, a submission that didn’t 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 didn’t previously
-win, then you are encouraged to mention this in your remarks.md file as this
-sometimes helps.
You are allowed to resubmit to a later contest, a submission that
+didn’t 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 didn’t previously win, then you are encouraged to
+mention this in your remarks.md file as this sometimes helps.
The clobber target MUST clean and restore the submission directory tree to
-its original state, such as removing temporary files or any modified data files.
-Don’t assume that git tool chain is installed, i.e. do NOT expect git clean -f to work. To be clear: do NOT use git to clean out files as this
-can cause problems in the winner repo!
The clobber target MUST clean and restore the submission
+directory tree to its original state, such as removing temporary files
+or any modified data files. Don’t assume that git tool chain is
+installed, i.e. do NOT expect git clean -f to work. To be clear:
+do NOT use git to clean out files as this WILL cause problems
+in the winner repo!
SHELL= bashDo NOT assume that . (current directory) is in the $PATH environment variable.
Do NOT assume that . (current directory) is in the $PATH
+environment variable.
See -FAQ on “What are the detailed recommendations for a submission Makefile?”.
-See Guidelines for Rule 15 - GNU Makefile.
+FAQ on “What are the detailed recommendations for a submission +Makefile?”. +See Guidelines for Rule 15 - GNU +Makefile.
Your source code, data files, remarks, and program output MUST NOT identify the author(s) of your code (unless you are Peter Honeyman or pretending to be Peter Honeyman). In order to be impartial the -Judges do NOT know who is submitting -programs to the IOCCC until final selection is made, and only submissions -that won.
+Judges do NOT know who is +submitting programs to the IOCCC until final selection is made, and +only submissions that won.Even if you are a past winner, you MUST NOT reveal your identity -deliberately or by accident anywhere in your submission. Failure to comply -may result in the submission being disqualified.
+deliberately or by accident anywhere in your submission. Failure to +comply may result in the submission being disqualified.mkiocccentryTL;DR: use mkiocccentry(1) to package your submission.
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.
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.
The submission MUST be a .txz compressed tarball (i.e., tarball compressed by xz(1))
-as constructed by mkiocccentry(1), which MUST be within [1..3999971] bytes in size.
The tarball MUST be a v7 format tarball, and any supplementary tarballs -you provide MUST also be v7 format.
-The sum of all file lengths, after unpacking from the tarball, MUST be
-less than 27651*1024 (28314624) bytes.
The submission MUST be a .txz compressed tarball (i.e., tarball
+compressed by xz(1)) as constructed by mkiocccentry(1), which
+MUST be within [1..3999971] bytes in size.
The tarball MUST be a v7 format tarball, and any supplementary +tarballs you provide MUST also be v7 format.
+The sum of all file lengths, after unpacking from the tarball, MUST
+be less than 27651*1024 (28314624) bytes.
See the -FAQ on “What is the mkiocccentry tool, how do I obtain it and how do I use it?”.
-See the Guidelines for Rule 17 - Use mkiocccentry.
+FAQ on “What is the mkiocccentry tool, how do I obtain it and how do I +use it?”. +See the Guidelines for Rule 17 - Use +mkiocccentry.
The entirety of your submission MUST be submitted under the following license:
-CC BY-SA 4.0 DEED Attribution-ShareAlike 4.0 International
+The entirety of your submission MUST be submitted under the +following license:
+CC BY-SA 4.0 DEED Attribution-ShareAlike 4.0 +International.
See Rule 6 - Free Rule.
Please read the Guidelines next for further commentary on these rules.
+Please read the Guidelines next for further +commentary on these rules.
Read the -Entering the IOCCC: the bare minimum you need to know +FAQ on “Entering the IOCCC: the bare minimum you need to +know” for an overview of how to enter the contest.
-See also the FAQ.
+See also the FAQ in general.
And now for something completely different.
-Consider joining the IOCCC Discord Server
-for discussions about The Rules, questions for the Judges, and C in general.
Consider joining the IOCCC Discord
+Server for discussions about
+The Rules, questions for the Judges, and C in general.
Leonid A. Broukhis chongo (Landon Curt Noll) /\cc/\
diff --git a/next/rules.md b/next/rules.md index 1d036387b0..980f1f515d 100644 --- a/next/rules.md +++ b/next/rules.md @@ -3,26 +3,27 @@ # The IOCCC is closed The IOCCC is **NOT** accepting new submissions at this time. See the -[IOCCC winning entries page](../years.html) for the entries that have won the -IOCCC in the past. +[IOCCC winning entries page](../years.html) for the entries that have +won the IOCCC in the past. -These rules are a **TENTATIVE proposal** for the next IOCCC -and are **likely be to be updated** before the next IOCCC. +These rules are a **TENTATIVE proposal** for the next IOCCC and are +**likely be to be updated** before the next IOCCC. See our FAQ on "[rules, guidelines, tools feedback](../faq.html#feedback)" as well as our FAQ on "[about asking questions](../faq.html#question)" -about these rules. You might also find the FAQ in general useful, especially the +about these rules. You might also find the FAQ in general useful, +especially the FAQ on "[how to enter the IOCCC](../quick-start.html#enter)". -Watch both [the IOCCC status page](../status.html) and the -[@IOCCC mastodon feed](https://fosstodon.org/@ioccc) for information about +Watch both [the IOCCC status page](../status.html) and the [@IOCCC +mastodon feed](https://fosstodon.org/@ioccc) for information about future IOCCC openings. **HINT to mastodon users**: You may wish to refresh the [@IOCCC -mastodon feed](https://fosstodon.org/@ioccc) page and/or mastodon -app from time to time to view IOCCC mastodon updates. +mastodon feed](https://fosstodon.org/@ioccc) page and/or mastodon app +from time to time to view IOCCC mastodon updates. @@ -39,14 +40,16 @@ writing by [contacting the judges](../contact.html). ## Rules Version -These IOCCC Rules are version **29.13 2025-12-01**. +These IOCCC Rules are version **29.14 2025-12-02**. Reminder: be SURE to read the [IOCCC guidelines](guidelines.html). @@ -57,34 +60,41 @@ Reminder: be SURE to read the [IOCCC guidelines](guidelines.html).