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:
+ +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.
Be sure to read the Rules.
Do NOT register more than one account just to try and get around -the limit on the number of submission slots.
+the limit on the number of submission slots, because if you do and we +discover that you did so your submissions will be rejected for +violating the rules.Jump to: top
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:
- -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.
@@ -917,6 +920,7 @@You should consider how your submission looks in each of the above tests. You should ask yourself if your submission remains obscure @@ -949,7 +953,7 @@
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
+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 @@ -960,6 +964,37 @@
A clean looking program with misleading comments and variable names might be a VERY GOOD START to a great submission!
+Try to avoid submissions that play music that some people believe is +copyrighted music.
+Did we remember to indicate that programs that blatantly use some +complex state machine to do something simple, are boring? We think we +did. :-)
+Given two versions of the same program, one that is a compact blob of +code, and the other that is formatted more like a typical C program, we +tend to favor the second version. Of course, a third version of the +same program that is formatted in an interesting and/or obfuscated way, +would definitely win over the first two!
+Remember, you can submit more than one submission. See 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
+FAQ on “What are the detailed recommendations for a submission
+Makefile”), do not
+assume this sort of code will work:
char *T = "So many primes, so little time!";
+ ...
+ T[14] = ';'; /* modifying a string requires: -fwritable-strings */Even so, one should probably not assume that this is universally +accepted.
+Initialized char arrays are OK to write over. For instance, this is +OK:
+ char b[] = "Is this OK";
+ b[9] = 'k'; /* modifying an initialized char array is OK */Jump to: top
try.alt
rule as well.
+We tend to DISLIKE programs that:
+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 +your submission.
Jump to: top
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.
#include of standard header files, just files you provide,
+or system files such as /usr/share/dict/words.
On 28 January 2007, the Judges rescinded the requirement that the #
in a C preprocessor directive must be the 1st non-whitespace byte.
gotosexit(3)Programs that claim to be the smallest C source that does something, really +better be the smallest such program or they risk being rejected because +they do not work as documented.
We suggest that you avoid trying for the ‘smallest self-replicating’ source. The smallest, a zero byte entry, won in 1994.
One line programs should be short one line programs: say around 80 +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
@@ -1150,38 +1219,14 @@
We tend to DISLIKE programs that:
-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 -your submission.
The program must compile and link cleanly in a Single UNIX Specification (UNIX-like) environment. Therefore do not assume the system has a windows.h include file:
#include <windows.h> /* we DISLIKE this */Other windows, on the other hand, might be OK: especially where “X +marks the spot”. Yet on the third hand, windows are best when they +are “unseen” (i.e., not dirty). :-)
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:
- main;Unless you specify -fwritable-strings (see COTHER in the example
-Makefile, described in the
-FAQ on “What are the detailed recommendations for a submission
-Makefile”), do not
-assume this sort of code will work:
char *T = "So many primes, so little time!";
- ...
- T[14] = ';'; /* modifying a string requires: -fwritable-strings */Even so, one should probably not assume that this is universally -accepted.
-Initialized char arrays are OK to write over. For instance, this is -OK:
- char b[] = "Is this OK";
- b[9] = 'k'; /* modifying an initialized char array is OK */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**.
@@ -1244,18 +1258,18 @@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 +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.
+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. +“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.
@@ -1264,8 +1278,9 @@X client submissions should try to not to depend on particular items in
.Xdefaults. If you must do so, be sure to note the required lines in
-the your remarks.md file. They should also not depend on any
-particular window manager.
remarks.md file.
+X client submissions should also not depend on any particular window +manager.
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 +
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.
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 +will try formatting their submission using a “normal” formatting style +such that at first glance (if you squint and don’t look at the details) +the code might pass for non-obfuscated C. Deceptive comments, and misleading formatting, in some cases, may be a plus. On the other hand, a misleading code style requires more source bytes.
If you do elect to use misleading formatting and comments, we suggest
you remark on this point in your remarks.md where you talk about why
-you think your submission is obfuscated. 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 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. :-)
Try to be even more creative!
Jump to: top
While we recognize that UNIX is not a universal operating system, the @@ -1354,6 +1368,7 @@
Some types of programs can’t excel (anti-tm) in some areas. Your program doesn’t have to excel in all areas, but doing well in several areas really does help.
+Try to be even more creative!
If there are limitations in your submission, you are highly encouraged
to note such limitations in your remarks.md file. For example if
your submission factors values up to a certain size, you might want to
@@ -1432,11 +1447,11 @@
iocccsize(1)txzchk(1)fnamchk(1)chksubmit(1)chkentry(1)Do NOT use txzchk(1) or fnamchk(1) command line options that
are labelled “for TESTING purposes” in their respective man pages.
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.
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 Use The The To help with not having to repeatedly enter a UUID, put your UUID into
-a file and use mkiocccentry -Y -i answers .. to force a yes answers with great
+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.mkiocccentry -i answers .. will still be required to confirm
-“Yes/No” questions. While mkiocccentry -Y -i answers .. will force
+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.mkiocccentry -u uuidfile ..., or use mkiocccentry -U UUID ... to give the UUID on the command line.mkiocccentry -u uuidfile ..., or use mkiocccentry -U UUID ... to give the UUID on the command line. If you also use -a answers or -A answers the UUID will be recorded, assuming it is a
+valid UUID.
If you wish to test that your submission passes 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
@@ -1499,12 +1515,15 @@
Once the tarball is packaged it will run txzchk(1), which will also
-run fnamchk(1), as part of its algorithm.
Once the submission directory has been constructed the
+mkiocccentry(1) tool will run chksubmit(1) to verify everything is
+well, before forming the tarball.
Once the tarball is formed mkiocccentry(1) will run txzchk(1),
+which will also run fnamchk(1), as part of its algorithm.
README.mdindex.htmlprogprog.altprog.alt.oprog.orig.c[0-9][0-9][0-9][0-9]_*.tar.bz2 file globMakefile, the mkiocccentry(1) tool will ONLY check file size.
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 diff --git a/next/guidelines.md b/next/guidelines.md index e9e53ecef8..060919dbb7 100644 --- a/next/guidelines.md +++ b/next/guidelines.md @@ -26,6 +26,32 @@ Because the **IOCCC29** was a substantial rewrite, only **important changes** from **IOCCC28** have been marked.
+