mirror/ioccc
1
0 Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

improvements to Rule 2 in rules and guidelines

Browse Source
This commit is contained in:
Landon Curt Noll committed 2024-06-24 18:10:15 -07:00
1 parent b35d280cd1
commit 93081c8f5d
4 files changed
+214 -149
Download Patch File Download Diff File Expand all files Collapse all files

No files matched your search

next/guidelines.html
+62 -64
View File
@@ -483,7 +483,7 @@ to attempt to exploit them. We will award ‘<em>Worst abuse of the rules</em>
the effort to debug an entry that has a slight problem, particularly
in or near the final round. On the other hand, we have seen some
of the best entries fall down because they didn’t work.</p>
<p>We tend to look down on a <a href="https://en.wikipedia.org/wiki/Prime_number">prime
<p><strong><code>|</code></strong> We tend to look down on a <a href="https://en.wikipedia.org/wiki/Prime_number">prime
number</a> printer that claims that
16 is a prime number. If you do have a bug, you are better off
documenting it. Noting “<em>this entry sometimes prints the 4th power
@@ -491,7 +491,7 @@ of a prime by mistake</em>” would save the above entry. And sometimes,
a strange bug/feature can even help the entry! Of course, a correctly
working entry is best. Clever people will note that 16 might be prime
under certain conditions. Wise people, when submitting something clever
will fully explain such cleverness in their entry’s remarks file.</p>
will fully explain such cleverness in their entry’s <code>remarks.md</code> file.</p>
<p>People who are considering to just use some complex mathematical
function or state machine to spell out something such as “<em>hello,
world!</em>” really really, and we do mean really, do need to be more creative.</p>
@@ -503,17 +503,17 @@ misleading comments and variable names might be a good start.</p>
<p>When programs use VTxxx/ANSI sequences, they should NOT be limited to a
specific terminal brand. Those programs that work in a standard xterm
are considered more portable.</p>
<p><strong><code>|</code></strong> <a href="rules.html#rule2">Rule 2</a> (the size rule) refers to the use of the IOCCC size tool called <code>iocccsize</code>.</p>
<p><strong><code>|</code></strong> See the <a href="https://github.com/ioccc-src/mkiocccentry">mkiocccentry toolkit</a> for the <code>iocccsize</code> tool.</p>
<p><strong><code>|</code></strong> To further clarify <a href="rules.html#rule2">Rule 2</a>, we subdivided it into two parts, 2a and 2b.</p>
<p><strong><code>|</code></strong> The overall size limit (see <a href="rules.html#rule2a">Rule 2a</a>) on <code>prog.c</code> is now 4993 bytes</p>
<p><strong><code>|</code></strong> <a href="rules.html#rule2">Rule 2</a> (the size rule) refers to the use of the IOCCC size tool called <code>iocccsize(1)</code>.</p>
<p><strong><code>|</code></strong> See the <a href="https://github.com/ioccc-src/mkiocccentry">mkiocccentry toolkit</a> for the <code>iocccsize(1)</code> tool.</p>
<p><strong><code>|</code></strong> To further clarify <a href="rules.html#rule2">Rule 2</a>, we subdivided it into two parts, <strong>2a</strong> and <strong>2b</strong>.</p>
<p><strong><code>|</code></strong> The overall size limit (see <a href="rules.html#rule2a">Rule 2a</a>) on <code>prog.c</code> is now <strong>4993 bytes</strong>.</p>
<p><strong><code>|</code></strong> Your entry must satisfy BOTH the maximum size <a href="rules.html#rule2a">Rule 2a</a> AND your entry
must satisfy the IOCCC size tool <a href="rules.html#rule2b">Rule 2b</a>.</p>
<p>This tool imposes a 2nd limit on C code size (see <a href="rules.html#rule2a">Rule 2a</a>. To check your
code against the 2nd limit of <a href="rules.html#rule2">Rule 2</a>, use the -i command line option.
For example:</p>
<pre><code> ./iocccsize -i &lt; prog.c</code></pre>
<p>The IOCCC size tool, when using the -i option, may be summarized as:</p>
<pre><code> ./iocccsize prog.c</code></pre>
<p><strong><code>|</code></strong> The IOCCC size tool algorithm may be summarized as follows:</p>
<pre><code> The size tool counts most C reserved words (keyword, secondary,
and selected preprocessor keywords) as 1. The size tool counts all
other octets as 1 excluding ASCII whitespace, and excluding any
@@ -555,7 +555,7 @@ both clang and gcc</li>
tend to ‘see thru’ masses of <code>#defines</code> due to our pre-processor tests
that we apply. Simply abusing <code>#defines</code> or <code>-Dfoo=bar</code> won’t go as far
as a program that is more well rounded in confusion.</p>
<p>Many C compilers dislike the following code, and so do we:</p>
<p>Many C compilers <strong>DISLIKE</strong> the following code, and so do we:</p>
<pre><code> #define d define
#d foo /* &lt;-- don&#39;t expect this to turn into #define foo */</code></pre>
<p>When declaring local or global variables, you should declare the type:</p>
@@ -567,10 +567,10 @@ c11 (formerly C1X) C compiler (ISO/IEC 9899:2011).</p>
must use an optional c11 feature, use feature test macros so
that implementations without such optional c11 features will see
an entry that is both functional and interesting.</p>
<p>We like entries that have workarounds that allow someone with
an older c99 (ISO/IEC 9899:1999) compiler to be able to compile
<p>We <strong>LIKE</strong> entries that have workarounds that allow someone with
nean older c99 (ISO/IEC 9899:1999) compiler to be able to compile
and enjoy your entry.</p>
<p>We really like “lint free” code. However lint is a toll of the past.
<p>We really <strong>LIKE</strong> “lint free” code. However lint is a toll of the past.
So try to ensure that your entry compiles warning free. If possible,
to compile compile your code using:</p>
<pre><code> -Wall -Wextra -pedantic</code></pre>
@@ -581,11 +581,11 @@ to make your code compile warning free using:</p>
the <a href="../faq.html">FAQ</a>.</p>
<p>If you must turn off various warnings on the compile line such as:</p>
<pre><code> ... -Wno-empty-body -Wno-return-type ...</code></pre>
<p>be sure to clearly state so in your remarks <strong>AS WELL AS</strong> in
your “how to build” / Makefile.</p>
<p><strong><code>|</code></strong> be sure to clearly state so in your <code>remarks.md</code> file <strong>AS WELL AS</strong> in
your <code>Makefile</code>.</p>
<p>All other things being equal, a program that must turn off fewer
warnings will be considered better, for certain values of better.</p>
<p>Unless you clearly state otherwise in your remarks <strong>AS WELL AS</strong> in
<p><strong><code>|</code></strong> Unless you clearly state otherwise in your <code>remarks.md</code> file <strong>AS WELL AS</strong> in
your “how to build” / Makefile we will compile using:</p>
<pre><code> -O3 -std=c11</code></pre>
<p>Anyone care to submit an entry that makes gratuitous use of all
@@ -650,35 +650,31 @@ whether pigs have wings is likely to remain a debatable point to most.</p>
<p>One line programs should be short one line programs: say around 80 to 120
octets long. Going well beyond 140 octets is a bit too long to be called
a one-liner in our vague opinion.</p>
<p>We tend to dislike programs that:</p>
<p>We tend to <strong>DISLIKE</strong> programs that:</p>
<ul>
<li>are very hardware specific</li>
<li>are very OS version specific
(index/strchr differences are OK, but socket/streams specific
code is likely not to be)</li>
<li>dump core or have compiler warnings
(it is OK only if you warn us in the ‘remark’ header item)</li>
<li>won’t compile or run under a POSIX P1003.1/P1003.2 like systems</li>
<li>depend on a utility or application not normally found on most
most POSIX P1003.1/P1003.2 like systems</li>
<li>abuse the build file to get around the size limit</li>
<li>obfuscate by excessive use of ANSI trigraphs</li>
<li>are longer than they need to be</li>
<li>are “blob-ier” than they need to be</li>
<li>are rather similar to previous winners :-(</li>
<li>are too similar to previous losers :-)</li>
<li>are very OS version specific (index/strchr differences are OK, but socket/streams specific code is likely not to be)<br>
<strong><code>|</code></strong> * dump core or have compiler warnings (it is OK only if you warn us in your ‘remark,md’ file)<br>
<strong><code>|</code></strong> * won’t compile or run a <a href="https://en.wikipedia.org/wiki/Single_UNIX_Specification">Single UNIX Specification</a> environment</li>
<li>depend on a utility or application not normally found systems that conform to the <a href="https://en.wikipedia.org/wiki/Single_UNIX_Specification">Single UNIX Specification</a></li>
<li>abuse the build file to get around the size limit<br>
<strong><code>|</code></strong> * obfuscate by use of ANSI trigraphs<br>
<strong><code>|</code></strong> * are larger than they need to be<br>
<strong><code>|</code></strong> * have more lines than they need to have<br>
<strong><code>|</code></strong> * are “blob-ier” (just a pile of unformatted C code) than they need to be</li>
<li>are rather similar to <strong>previous winners</strong> :-(</li>
<li>are identical to <strong>previous losers</strong> :-)</li>
<li>that mandate the exclusive the use of an specific Integrated</li>
<li>Development Environment (IDE)</li>
</ul>
<p>In order to encourage entry portability, we dislike entries that
<p>In order to encourage entry portability, we <strong>DISLIKE</strong> entries 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 entry. Nevertheless some of the better IDEs have command-line
interfaces to their compilers, once one learns how to invoke a shell.</p>
<p>The program must compile and link cleanly in a POSIX-like environment.
Therefore do not assume the system has a
<p><strong><code>|</code></strong> The program must compile and link cleanly in a <a href="https://en.wikipedia.org/wiki/Single_UNIX_Specification">Single UNIX Specification</a> environment Therefore do not assume the system has a
<a href="https://en.wikipedia.org/wiki/Windows.h">windows.h</a> include file:</p>
<pre><code> #include &lt;windows.h&gt; /* we dislike this include */</code></pre>
<pre><code> #include &lt;windows.h&gt; /* we DISLIKE this include */</code></pre>
<p>Unless you are cramped for space, or unless you are entering the
‘<em>Best one liner</em>’ category, we suggest that you format your program
in a more creative way than simply forming excessively long lines.</p>
@@ -697,9 +693,10 @@ bytes of <code>-D</code>s in order to try and squeeze the source under the size
<p>The judges, as a group, have a history giving wide degree of latitude
to reasonable entries. And recently they have had as much longitudinal
variation as it is possible to have on Earth. :-)</p>
<p>You should try to restrict commands used on the build file to
POSIX-like or common Unix-like commands. You can also compile
and use your own programs. If you do, try to build and execute
<p><strong><code>|</code></strong> You should try to restrict commands used on the build file to
commands found in <a href="https://en.wikipedia.org/wiki/Single_UNIX_Specification">Single UNIX Specification</a> environments
and systems that conform to the <a href="https://en.wikipedia.org/wiki/Single_UNIX_Specification">Single UNIX Specification</a>.</p>
<p><strong><code>|</code></strong> 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 if your
program is reasonably portable.</p>
@@ -721,13 +718,13 @@ For example, one could use the build instructions:</p>
<pre><code> prog: prog.c
${CC} prog.c -DNON_HUMAN_COMPILE -o prog
@echo &quot;See remarks section about alternate ways to compile&quot;</code></pre>
<p>and then include special notes in the program “remarks” for
<p>and then include special notes in tour <code>remarks.md</code> file for
alternate / human intervention based building.</p>
<p>We want to get away from source that is simply a compact blob of
octets. Really try to be more creative than blob coding. <strong>HINT!</strong></p>
<p>Please do not use things like <code>gzip(1)</code> to get around the size limit.
Please try to be much more creative.</p>
<p>We really dislike entries that make blatant use of including
<p>We really <strong>DISLIKE</strong> entries that make blatant use of including
large data files to get around the source code size limit.</p>
<p>We do not recommend submitting <a href="https://systemd.io">systemd</a> source code to the IOCCC,
if nothing else because that code is likely to exceed the source code
@@ -753,7 +750,7 @@ they do not work as documented.</p>
<p>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:</p>
<pre><code> main;</code></pre>
<p>We do not like writable strings. That is, we don’t want stuff like:</p>
<p>We do <strong>DISLIKE</strong> writable strings. That is, we don’t want stuff such as:</p>
<pre><code> char *T = &quot;So many primes, so little time!&quot;;
...
T[14] = &#39;;&#39;;</code></pre>
@@ -776,13 +773,13 @@ software that is not in wide spread use.</p>
<p><strong><code>|</code></strong> However, do you know how to play <a href="https://en.wikipedia.org/wiki/List_of_games_in_Star_Trek#Fizzbin">fizzbin</a>?
You do?!? (Except on Tuesday?)</p>
<p><strong><code>|</code></strong> OK, there are actually 3 <em>guidelines</em> that contain the word fizzbin.</p>
<p>We don’t like entries that use proprietary toolkits such as the <code>M*tif</code>,
<p>We <strong>DISLIKE</strong> entries that use proprietary toolkits such as the <code>M*tif</code>,
<code>Xv*ew</code>, or <code>OpenL*ok</code> toolkits, since not everyone has them. Use an
open source toolkit that is widely and freely available instead.</p>
<p><strong>NOTE</strong>: The previous <em>guideline</em> in this spot has been replaced by this <em>guideline</em>:</p>
<p>X client entries should not to depend on particular items on
<p><strong><code>|</code></strong> X client entries should not to depend on particular items on
<code>.Xdefaults</code>. If you must do so, be sure to note the required lines
in the program “remarks”. They should also not depend on any
in the your <code>remarks.md</code> file. They should also not depend on any
particular window manager.</p>
<p>Try to avoid entries that play silent sound segments or play the
Happy Birthday song; music that some people believe is copyrighted
@@ -802,7 +799,7 @@ the scope of the contest, we phrase our bias to favor:</p>
<p>Any complaints about the above <em>guideline</em> could be addressed to the
Speaker of the House of Commons, or to the speaker of your national
parliament should you have one.</p>
<p>We like programs that:</p>
<p>We <strong>LIKE</strong> programs that:</p>
<ul>
<li>are as concise and small as they need to be</li>
<li>do something at least quasi-interesting</li>
@@ -815,17 +812,17 @@ parliament should you have one.</p>
<p>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.</p>
<p>You are better off explaining what your entry does in the program
“remarks” section rather than leaving it obscure for the judges
<p><strong><code>|</code></strong> You are better off explaining what your entry does in your
<code>remarks.md</code> file section rather than leaving it obscure for the judges
as we might miss something and/or be too tired to notice.</p>
<p><strong><code>|</code></strong> Please avoid this specific individual <em>guideline</em>, if it at all possible.</p>
<p>We freely admit that interesting, creative or humorous comments in
the program “remarks” help your chances of winning. If you had to
<p><strong><code>|</code></strong> We freely admit that interesting, creative or humorous comments in
your <code>remarks.md</code> file help your chances of winning. If you had to
read so many twisted entries, you too would enjoy a good laugh or two.
We think the readers of the contest winners do as well. We do read
the program “remarks” during the judging process, so it is worth your
while to write remarkable program “remarks”.</p>
<p>We dislike C code with trailing control-M’s (<code>\r</code> or <code>\015</code>) that results
the your <code>remarks.md</code> content during the judging process, so it is worth your
while to write remarkable <code>remarks.md</code> file.</p>
<p>We <strong>DISLIKE</strong> C code with trailing control-M’s (<code>\r</code> or <code>\015</code>) 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
@@ -842,7 +839,7 @@ Instead of unescaped octets, you should use or escapes:</p>
/* This octet requires 4 octets of source ^^^^ */
if (strlen(foo) == 36) printf(&quot;foo is 36 octets plus a final NUL\n&quot;);
else printf(&quot;This code should not print this message\n&quot;);</code></pre>
<p>It is a very good idea to, in your remarks file, tell us why you
<p><strong><code>|</code></strong> It is a very good idea to, in your <code>remarks.md</code> file, tell us why you
think your entry is obfuscated. This is particularly true if
your entry is has some very subtle obfuscations that we might
otherwise overlook. <strong>&lt;&lt;– Hint!</strong></p>
@@ -859,7 +856,7 @@ 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!</p>
<p>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 i386 or x86 architecture.</p>
<p>We believe that Mark Twain’s remark:</p>
<p>We believe that Mark Twain’s once wrote:</p>
<blockquote>
<p>Get your facts first, then you can distort them as you please.</p>
</blockquote>
@@ -876,8 +873,8 @@ interesting than simply implementing the IOCCC size tool algorithm.</p>
to pick, choose a 64-bit word size.</p>
<p>If we are feeling ornery we might choose to compile your program
for running on an Arduino or a PDP-11. Heck, should we ever find
an emulator of 60-bit CDC Cyber CPU running a POSIX-like OS, we
might just try your entry on that emulator as well :-)</p>
an emulator of 60-bit CDC Cyber CPU, we might just try your entry
on that emulator as well :-)</p>
<p>If your entry MUST run only in 32-bit mode on an Intel processor, add the
following compiler flag:</p>
<pre><code> -arch i386</code></pre>
@@ -885,8 +882,8 @@ following compiler flag:</p>
<pre><code> prog: prog.c
${CC} prog.c -arch i386 -o prog</code></pre>
<p>Be even more creative!</p>
<p>If there are limitations in your entry, you are highly encouraged
to note such limitations in your remarks file. For example if your
<p><strong><code>|</code></strong> If there are limitations in your entry, you are highly encouraged
to note such limitations in your <code>remarks.md</code> file. For example if your
entry factors values up to a certain size, you might want to state:</p>
<pre><code> This entry factors values up 2305567963945518424753102147331756070.
Attempting to factor larger values will produce unpredictable results.</code></pre>
@@ -913,10 +910,11 @@ and state:</p>
<pre><code> This entry 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.</code></pre>
<p><strong><code>|</code></strong> Do not fear if you not 100% sure of the significance of <code>2305567963945518424753102147331756070</code> as it is not of prime importance: or is it? :-)</p>
<p><strong><code>|</code></strong> We <strong>DISLIKE</strong> the use of use ASCII tab characters in markdown files, such as in the required <code>remarks.md</code> file.</p>
<p><strong><code>|</code></strong> We don’t mind the use ASCII tab characters in your C code. Feel free to use ASCII tab characters if that suits your obfuscation needs. If is perfectly <strong>OK</strong> to use tab characters elsewhere in your submission, just not in markdown files as this tends complicate and annoys us when be comes to rendering your markdown content.</p>
<p><strong><code>|</code></strong> If you do use ASCII tab characters in your non-markdown files, be aware that some people may use tab stop that is different than the common 8 character tab stop.</p>
<p><strong><code>|</code></strong> We enjoy a reading <code>remarks.md</code> files, especially if they contain useful, informative, and even humorous content about your entry.</p>
<p><strong><code>|</code></strong> We <strong>LIKE</strong> a reading <code>remarks.md</code> files, especially if they contain useful, informative, and even humorous content about your entry. Yes, this is a <strong>hint</strong>. :-)</p>
<p><strong><code>|</code></strong> We <strong>RECOMMEND</strong> you put a reasonable amount effort into the content of the <code>remarks.md</code> file: it is a required for for a reason. :-)</p>
<h1 id="abusing-the-rules">ABUSING THE RULES:</h1>
<p>Legal abuse of the <a href="rules.html">IOCCC rules</a> is somewhat encouraged. Legal rule abuse
@@ -933,8 +931,8 @@ disqualified. <strong><em>RULE ABUSE CARRIES A CERTAIN LEVEL OF RISK!</em></stro
have an entry that might otherwise be interesting, you might want to
submit two versions; one that does not abuse the <a href="rules.html">IOCCC rules</a> and one that
does.</p>
<p>If you intend to abuse the <a href="rules.html">IOCCC rules</a>, indicate so in the program
“remarks”. You must try to justify why you consider your rule abuse to be
<p><strong><code>|</code></strong> If you intend to abuse the <a href="rules.html">IOCCC rules</a>, indicate so in the program
<code>remarks.md</code> file. You must try to justify why you consider your rule abuse to be
allowed under the <a href="rules.html">IOCCC rules</a>. That is, you must plead your case as to
why your entry is valid. Humor and/or creativity help plead a case.</p>
<p>Abusing the web submission procedure tends to annoy us more
@@ -991,9 +989,9 @@ won an award. So it is theoretically possible that Peter Honeyman
did submit an entry in the past. In the past, Peter had denied
submitting anything to the IOCCC. Perhaps those entries were
submitted by one of his students?</p>
<p>Hopefully we are <strong>VERY CLEAR</strong> on this point! The rules now strongly state:
<p><strong><code>|</code></strong> Hopefully we are <strong>VERY CLEAR</strong> on this point! The rules now strongly state:
<strong>PLEASE <em>DO NOT</em> put a name of an author</strong>, in an obvious way, into your
source code, remarks, data files, etc. The above “Peter Honeyman is
source code, <code>remarks.md</code>, data files, etc. The above “Peter Honeyman is
exempt” notwithstanding.</p>
<p>We seemed to have digressed again … :-) Returning to the judging process:</p>
<p>We prefer to be kept in the dark as much as you are until the final
@@ -1015,8 +1013,8 @@ previous round. Thus, an entry gets at least two readings.</p>
<p>A reading consists of a number of actions:</p>
<ul>
<li>reading the “how to build” information and forming a Makefile</li>
<li>reading prog.c, the C source</li>
<li>reviewing the “remarks” information</li>
<li>reading prog.c, the C source
<strong><code>|</code></strong> * reviewing the <code>remarks.md</code> information</li>
<li>briefly looking any any supplied data files</li>
<li>passing the source thru the C pre-processor
skipping over any #include files</li>
next/guidelines.md
+63 -63
View File
@@ -142,7 +142,7 @@ the effort to debug an entry that has a slight problem, particularly
in or near the final round. On the other hand, we have seen some
of the best entries fall down because they didn't work.
We tend to look down on a [prime
**`|`** We tend to look down on a [prime
number](https://en.wikipedia.org/wiki/Prime_number) printer that claims that
16 is a prime number. If you do have a bug, you are better off
documenting it. Noting "_this entry sometimes prints the 4th power
@@ -150,7 +150,7 @@ of a prime by mistake_" would save the above entry. And sometimes,
a strange bug/feature can even help the entry! Of course, a correctly
working entry is best. Clever people will note that 16 might be prime
under certain conditions. Wise people, when submitting something clever
will fully explain such cleverness in their entry's remarks file.
will fully explain such cleverness in their entry'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,
@@ -166,13 +166,13 @@ When programs use VTxxx/ANSI sequences, they should NOT be limited to a
specific terminal brand. Those programs that work in a standard xterm
are considered more portable.
**`|`** [Rule 2](rules.html#rule2) (the size rule) refers to the use of the IOCCC size tool called `iocccsize`.
**`|`** [Rule 2](rules.html#rule2) (the size rule) refers to the use of the IOCCC size tool called `iocccsize(1)`.
**`|`** See the [mkiocccentry toolkit](https://github.com/ioccc-src/mkiocccentry) for the `iocccsize` tool.
**`|`** See the [mkiocccentry toolkit](https://github.com/ioccc-src/mkiocccentry) for the `iocccsize(1)` tool.
**`|`** To further clarify [Rule 2](rules.html#rule2), we subdivided it into two parts, 2a and 2b.
**`|`** To further clarify [Rule 2](rules.html#rule2), we subdivided it into two parts, **2a** and **2b**.
**`|`** The overall size limit (see [Rule 2a](rules.html#rule2a)) on `prog.c` is now 4993 bytes
**`|`** The overall size limit (see [Rule 2a](rules.html#rule2a)) on `prog.c` is now **4993 bytes**.
**`|`** Your entry must satisfy BOTH the maximum size [Rule 2a](rules.html#rule2a) AND your entry
must satisfy the IOCCC size tool [Rule 2b](rules.html#rule2b).
@@ -182,10 +182,10 @@ code against the 2nd limit of [Rule 2](rules.html#rule2), use the -i command lin
For example:
```
./iocccsize -i < prog.c
./iocccsize prog.c
```
The IOCCC size tool, when using the -i option, may be summarized as:
**`|`** The IOCCC size tool algorithm may be summarized as follows:
```
The size tool counts most C reserved words (keyword, secondary,
@@ -241,7 +241,7 @@ 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.
Many C compilers dislike the following code, and so do we:
Many C compilers **DISLIKE** the following code, and so do we:
``` <!---c-->
#define d define
@@ -263,11 +263,11 @@ must use an optional c11 feature, use feature test macros so
that implementations without such optional c11 features will see
an entry that is both functional and interesting.
We like entries that have workarounds that allow someone with
an older c99 (ISO/IEC 9899:1999) compiler to be able to compile
We **LIKE** entries that have workarounds that allow someone with
nean older c99 (ISO/IEC 9899:1999) compiler to be able to compile
and enjoy your entry.
We really like "lint free" code. However lint is a toll of the past.
We really **LIKE** "lint free" code. However lint is a toll of the past.
So try to ensure that your entry compiles warning free. If possible,
to compile compile your code using:
@@ -292,13 +292,13 @@ If you must turn off various warnings on the compile line such as:
... -Wno-empty-body -Wno-return-type ...
```
be sure to clearly state so in your remarks **AS WELL AS** in
your "how to build" / Makefile.
**`|`** be sure to clearly state so in your `remarks.md` file **AS WELL AS** in
your `Makefile`.
All other things being equal, a program that must turn off fewer
warnings will be considered better, for certain values of better.
Unless you clearly state otherwise in your remarks **AS WELL AS** in
**`|`** Unless you clearly state otherwise in your `remarks.md` file **AS WELL AS** in
your "how to build" / Makefile we will compile using:
```
@@ -388,38 +388,34 @@ One line programs should be short one line programs: say around 80 to 120
octets long. Going well beyond 140 octets is a bit too long to be called
a one-liner in our vague opinion.
We tend to dislike programs that:
We tend to **DISLIKE** programs that:
* are very hardware specific
* are very OS version specific
(index/strchr differences are OK, but socket/streams specific
code is likely not to be)
* dump core or have compiler warnings
(it is OK only if you warn us in the 'remark' header item)
* won't compile or run under a POSIX P1003.1/P1003.2 like systems
* depend on a utility or application not normally found on most
most POSIX P1003.1/P1003.2 like systems
* abuse the build file to get around the size limit
* obfuscate by excessive use of ANSI trigraphs
* are longer than they need to be
* are "blob-ier" than they need to be
* are rather similar to previous winners :-(
* are too similar to previous losers :-)
* are very OS version specific (index/strchr differences are OK, but socket/streams specific code is likely not to be)<br>
**`|`** * dump core or have compiler warnings (it is OK only if you warn us in your 'remark,md' file)<br>
**`|`** * won't compile or run a [Single UNIX Specification](https://en.wikipedia.org/wiki/Single_UNIX_Specification) environment
* depend on a utility or application not normally found systems that conform to the [Single UNIX Specification](https://en.wikipedia.org/wiki/Single_UNIX_Specification)
* abuse the build file to get around the size limit<br>
**`|`** * obfuscate by use of ANSI trigraphs<br>
**`|`** * are larger than they need to be<br>
**`|`** * have more lines than they need to have<br>
**`|`** * are "blob-ier" (just a pile of unformatted C code) than they need to be
* are rather similar to **previous winners** :-(
* are identical to **previous losers** :-)
* that mandate the exclusive the use of an specific Integrated
* Development Environment (IDE)
In order to encourage entry portability, we dislike entries that
In order to encourage entry portability, we **DISLIKE** entries 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 entry. Nevertheless some of the better IDEs have command-line
interfaces to their compilers, once one learns how to invoke a shell.
The program must compile and link cleanly in a POSIX-like environment.
Therefore do not assume the system has a
**`|`** The program must compile and link cleanly in a [Single UNIX Specification](https://en.wikipedia.org/wiki/Single_UNIX_Specification) environment Therefore do not assume the system has a
[windows.h](https://en.wikipedia.org/wiki/Windows.h) include file:
``` <!---c-->
#include <windows.h> /* we dislike this include */
#include <windows.h> /* we DISLIKE this include */
```
Unless you are cramped for space, or unless you are entering the
@@ -445,9 +441,11 @@ The judges, as a group, have a history giving wide degree of latitude
to reasonable entries. And recently they have had as much longitudinal
variation as it is possible to have on Earth. :-)
You should try to restrict commands used on the build file to
POSIX-like or common Unix-like commands. You can also compile
and use your own programs. If you do, try to build and execute
**`|`** You should try to restrict commands used on the build file to
commands found in [Single UNIX Specification](https://en.wikipedia.org/wiki/Single_UNIX_Specification) environments
and systems that conform to the [Single UNIX Specification](https://en.wikipedia.org/wiki/Single_UNIX_Specification).
**`|`** You may compile and use your own programs. If you do, try to build and execute
from the current directory. This restriction is not a hard and
absolute one. The intent is to ensure that the building if your
program is reasonably portable.
@@ -481,7 +479,7 @@ For example, one could use the build instructions:
@echo "See remarks section about alternate ways to compile"
```
and then include special notes in the program "remarks" for
and then include special notes in tour `remarks.md` file for
alternate / human intervention based building.
We want to get away from source that is simply a compact blob of
@@ -490,7 +488,7 @@ octets. Really try to be more creative than blob coding. **HINT!**
Please do not use things like `gzip(1)` to get around the size limit.
Please try to be much more creative.
We really dislike entries that make blatant use of including
We really **DISLIKE** entries that make blatant use of including
large data files to get around the source code size limit.
We do not recommend submitting [systemd](https://systemd.io) source code to the IOCCC,
@@ -525,7 +523,7 @@ is NOT the smallest C source file that when compiled and run, dumps core:
main;
```
We do not like writable strings. That is, we don't want stuff like:
We do **DISLIKE** writable strings. That is, we don't want stuff such as:
``` <!---c-->
char *T = "So many primes, so little time!";
@@ -562,15 +560,15 @@ You do?!? (Except on Tuesday?)
**`|`** OK, there are actually 3 _guidelines_ that contain the word fizzbin.
We don't like entries that use proprietary toolkits such as the `M*tif`,
We **DISLIKE** entries that use proprietary toolkits such as the `M*tif`,
`Xv*ew`, or `OpenL*ok` toolkits, since not everyone has them. Use an
open source toolkit that is widely and freely available instead.
**NOTE**: The previous _guideline_ in this spot has been replaced by this _guideline_:
X client entries should not to depend on particular items on
**`|`** X client entries should not to depend on particular items on
`.Xdefaults`. If you must do so, be sure to note the required lines
in the program "remarks". They should also not depend on any
in the your `remarks.md` file. They should also not depend on any
particular window manager.
Try to avoid entries that play silent sound segments or play the
@@ -597,7 +595,7 @@ 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 like programs that:
We **LIKE** programs that:
* are as concise and small as they need to be
* do something at least quasi-interesting
@@ -611,20 +609,20 @@ Some types of programs can't excel (anti-tm) in some areas. Your
program doesn't have to excel in all areas, but doing well in several
areas really does help.
You are better off explaining what your entry does in the program
"remarks" section rather than leaving it obscure for the judges
**`|`** You are better off explaining what your entry 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.
**`|`** Please avoid this specific individual _guideline_, if it at all possible.
We freely admit that interesting, creative or humorous comments in
the program "remarks" help your chances of winning. If you had to
**`|`** 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 entries, you too would enjoy a good laugh or two.
We think the readers of the contest winners do as well. We do read
the program "remarks" during the judging process, so it is worth your
while to write remarkable program "remarks".
the your `remarks.md` content during the judging process, so it is worth your
while to write remarkable `remarks.md` file.
We dislike C code with trailing control-M's (`\r` or `\015`) that results
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
@@ -647,7 +645,7 @@ Instead of unescaped octets, you should use \octal or \hex escapes:
else printf("This code should not print this message\n");
```
It is a very good idea to, in your remarks file, tell us why you
**`|`** It is a very good idea to, in your `remarks.md` file, tell us why you
think your entry is obfuscated. This is particularly true if
your entry is has some very subtle obfuscations that we might
otherwise overlook. **<<-- Hint!**
@@ -668,7 +666,7 @@ into creating a dense blob. Such are the trade-offs that obfuscators face!
We prefer code that can run on either a 64-bit or 32-bit processor.
However, it is unwise to assume it will run on an i386 or x86 architecture.
We believe that Mark Twain's remark:
We believe that Mark Twain's once wrote:
> Get your facts first, then you can distort them as you please.
@@ -689,8 +687,8 @@ to pick, choose a 64-bit word size.
If we are feeling ornery we might choose to compile your program
for running on an Arduino or a PDP-11. Heck, should we ever find
an emulator of 60-bit CDC Cyber CPU running a POSIX-like OS, we
might just try your entry on that emulator as well :-)
an emulator of 60-bit CDC Cyber CPU, we might just try your entry
on that emulator as well :-)
If your entry MUST run only in 32-bit mode on an Intel processor, add the
following compiler flag:
@@ -708,8 +706,8 @@ to your "how to build" make compile line. For example:
Be even more creative!
If there are limitations in your entry, you are highly encouraged
to note such limitations in your remarks file. For example if your
**`|`** If there are limitations in your entry, you are highly encouraged
to note such limitations in your `remarks.md` file. For example if your
entry factors values up to a certain size, you might want to state:
```
@@ -764,13 +762,15 @@ and state:
might insult a fish named Eric.
```
**`|`** Do not fear if you not 100% sure of the significance of `2305567963945518424753102147331756070` as it is not of prime importance: or is it? :-)
**`|`** We **DISLIKE** the use of use ASCII tab characters in markdown files, such as in the required `remarks.md` file.
**`|`** We don't mind the use 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 complicate and annoys us when be comes to rendering your markdown content.
**`|`** If you do use ASCII tab characters in your non-markdown files, be aware that some people may use tab stop that is different than the common 8 character tab stop.
**`|`** We enjoy a reading `remarks.md` files, especially if they contain useful, informative, and even humorous content about your entry.
**`|`** We **LIKE** a reading `remarks.md` files, especially if they contain useful, informative, and even humorous content about your entry. 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 for for a reason. :-)
@@ -796,8 +796,8 @@ have an entry that might otherwise be interesting, you might want to
submit two versions; one that does not abuse the [IOCCC rules](rules.html) and one that
does.
If you intend to abuse the [IOCCC rules](rules.html), indicate so in the program
"remarks". You must try to justify why you consider your rule abuse to be
**`|`** If you intend to abuse the [IOCCC rules](rules.html), indicate so in the program
`remarks.md` file. You must try to justify why you consider your rule abuse to be
allowed under the [IOCCC rules](rules.html). That is, you must plead your case as to
why your entry is valid. Humor and/or creativity help plead a case.
@@ -867,9 +867,9 @@ did submit an entry in the past. In the past, Peter had denied
submitting anything to the IOCCC. Perhaps those entries were
submitted by one of his students?
Hopefully we are **VERY CLEAR** on this point! The rules now strongly state:
**`|`** Hopefully we are **VERY CLEAR** on this point! The rules now strongly state:
**PLEASE _DO NOT_ put a name of an author**, in an obvious way, into your
source code, remarks, data files, etc. The above "Peter Honeyman is
source code, `remarks.md`, data files, etc. The above "Peter Honeyman is
exempt" notwithstanding.
We seemed to have digressed again ... :-) Returning to the judging process:
@@ -898,7 +898,7 @@ A reading consists of a number of actions:
* reading the "how to build" information and forming a Makefile
* reading prog.c, the C source
* reviewing the "remarks" information
**`|`** * reviewing the `remarks.md` information
* briefly looking any any supplied data files
* passing the source thru the C pre-processor
skipping over any #include files
next/rules.html
+38 -11
View File
@@ -407,7 +407,7 @@ writing by <a href="../contact.html">contacting the judges</a>.</p>
<div id="rule_version">
<h2 id="ioccc-rules-version">IOCCC Rules version</h2>
</div>
<p><strong><code>|</code></strong> These <a href="rules.html">IOCCC rules</a> are version <strong>2024-06-23-v28</strong>.</p>
<p><strong><code>|</code></strong> These <a href="rules.html">IOCCC rules</a> are version <strong>2024-06-25-v28</strong>.</p>
<p><strong>IMPORTANT</strong>: Be sure to read the <a href="guidelines.html">IOCCC guidelines</a>.</p>
<h3 id="change-marks">Change marks</h3>
<p><strong><code>|</code></strong> <strong>← Lines that start with this symbol indicate a change from the previous IOCCC</strong></p>
@@ -469,17 +469,41 @@ entry submission URL.</p>
<div id="rule2a">
<h2 id="rule-2a">Rule 2a</h2>
</div>
<p><strong><code>|</code></strong> The size of your program source <strong>MUST BE &lt;= 4993 bytes</strong> in length.</p>
<p><strong><code>|</code></strong> The size of your program source <strong>should not exceed 4993 bytes</strong>.</p>
<p><strong><code>|</code></strong> If you use the most recently released official IOCCC submission packaging tool
(hereby referred to as <code>mkiocccentry(1)</code>), which we <strong>STRONGLY recommend you use</strong>,
then the <code>mkiocccentry(1)</code> tool will warn you if there appears to be a <a href="#rule2a">Rule 2a</a> violation.</p>
<p><strong><code>|</code></strong> The <code>mkiocccentry(1)</code> tool will give you the option of overriding the <a href="#rule2a">Rule 2a</a> warning.
Overriding a <a href="#rule2a">Rule 2a</a> warning carries a <strong>fair amount of risk</strong> that your submission
will be <strong>rejected</strong>. Be sure to consult the <a href="guidelines.html">IOCCC guidelines</a>
ahead of time if you plan to override the <a href="#rule2a">Rule 2a</a> warning.</p>
<p><strong><code>|</code></strong> If you do override the <a href="#rule2a">Rule 2a</a> warning from the <code>mkiocccentry(1)</code> tool,
or otherwise plan to violate <a href="#rule2a">Rule 2a</a>, then you <strong>must clearly explain the rationale</strong>
of why you are doing so in your <code>remarks.md</code> file. Even if you do explain this in your <code>remarks.md</code> file
your submission may still be rejected.</p>
<p><strong><code>|</code></strong> You may check your code prior to submission by giving the filename
as a command like argument to the <code>iocccsize(1)</code> tool. For example:</p>
<pre><code> ./iocccsize prog.c</code></pre>
<div id="rule2b">
<h2 id="rule-2b">Rule 2b</h2>
</div>
<p><strong><code>|</code></strong> When your program source is fed as input to the current IOCCC size
tool, and the IOCCC size tool <code>-i</code> command line option is used, the
value printed <strong>shall not exceed 2503</strong>.</p>
<p><strong><code>|</code></strong> The source to the current IOCCC size tool is found in the
<a href="https://github.com/ioccc-src/mkiocccentry">mkiocccentry tool repo</a>. If you use
the <code>mkiocccentry</code> tool (which we <strong>STRONGLY recommend you do</strong>) it will invoke
this tool before packaging your entry for submission.</p>
<p><strong><code>|</code></strong> When the filename of your program source is given as a command line argument to the latest version
of the official IOCCC size tool (hereby referred to as <code>iocccsize(1)</code>), the value printed <strong>should not exceed 2503</strong>.</p>
<p><strong><code>|</code></strong> The source to <code>iocccsize(1)</code> may be found in the
<a href="https://github.com/ioccc-src/mkiocccentry">mkiocccentry tool repo</a>.</p>
<p><strong><code>|</code></strong> If you use the <code>mkiocccentry(1)</code> tool, which we <strong>STRONGLY recommend you use</strong>,
then <code>mkiocccentry(1)</code> will invoke <code>iocccsize(1)</code> before packaging your entry for submission.</p>
<p><strong><code>|</code></strong> The <code>mkiocccentry(1)</code> tool will give you the option of overriding the <a href="#rule2b">Rule 2b</a> warning.
Overriding a <a href="#rule2b">Rule 2b</a> warning carries a <strong>fair amount of risk</strong> that your submission
will be <strong>rejected</strong>. Be sure to consult the <a href="guidelines.html">IOCCC guidelines</a>
ahead of time if you plan to override the <a href="#rule2b">Rule 2b</a> warning.</p>
<p><strong><code>|</code></strong> If you do override the <a href="#rule2b">Rule 2b</a> warning from the <code>mkiocccentry(1)</code> tool,
or otherwise plan to violate <a href="#rule2b">Rule 2a</a>, then you <strong>must clearly explain the rationale</strong>
of why you are doing so in your <code>remarks.md</code> file. Even if you do explain this in your <code>remarks.md</code> file
your submission may still be rejected.</p>
<p><strong><code>|</code></strong> You may check your code prior to submission by giving the filename
as a command like argument to the <code>iocccsize(1)</code> tool. For example:</p>
<pre><code> ./iocccsize prog.c</code></pre>
<div id="rule3">
<h2 id="rule-3">Rule 3</h2>
</div>
@@ -633,8 +657,11 @@ C source file must be called <code>prog.c</code>.</p>
To invoke the C preprocessor use <code>${CPP}</code>.</p>
<p>Do not assume that <code>.</code> (the current directory) is in the <code>$PATH</code>.</p>
<p>Use a shell command syntax that is compatible with bash.</p>
<p>Assume that commands commonly found in POSIX-like / Linux-like systems
are available in the search path.</p>
<p><strong><code>|</code></strong> Assume that commands commonly found in <a href="https://en.wikipedia.org/wiki/Single_UNIX_Specification">Single UNIX
Specification</a>
environments and systems that conform to the <a href="https://en.wikipedia.org/wiki/Single_UNIX_Specification">Single UNIX
Specification</a> are
available in the <code>$PATH</code> search path.</p>
<p>Do not assume any particular given value of <code>${CFLAGS}</code> or other
commonly used make variables. In other words you <strong>MUST</strong> specify the <code>CFLAGS</code>
to use.</p>
next/rules.md
+51 -11
View File
@@ -36,7 +36,7 @@ writing by [contacting the judges](../contact.html).
## IOCCC Rules version
</div>
**`|`** These [IOCCC rules](rules.html) are version **2024-06-23-v28**.
**`|`** These [IOCCC rules](rules.html) are version **2024-06-25-v28**.
**IMPORTANT**: Be sure to read the [IOCCC guidelines](guidelines.html).
@@ -133,22 +133,59 @@ The size rule requires your entry to satisfy **BOTH** [Rule 2a](#rule2a) and [Ru
## Rule 2a
</div>
**`|`** The size of your program source **MUST BE <= 4993 bytes** in length.
**`|`** The size of your program source **should not exceed 4993 bytes**.
**`|`** If you use the most recently released official IOCCC submission packaging tool
(hereby referred to as `mkiocccentry(1)`), which we **STRONGLY recommend you use**,
then the `mkiocccentry(1)` tool will warn you if there appears to be a [Rule 2a](#rule2a) violation.
**`|`** The `mkiocccentry(1)` tool will give you the option of overriding the [Rule 2a](#rule2a) warning.
Overriding a [Rule 2a](#rule2a) warning carries a **fair amount of risk** that your submission
will be **rejected**. Be sure to consult the [IOCCC guidelines](guidelines.html)
ahead of time if you plan to override the [Rule 2a](#rule2a) warning.
**`|`** If you do override the [Rule 2a](#rule2a) warning from the `mkiocccentry(1)` tool,
or otherwise plan to violate [Rule 2a](#rule2a), then you **must clearly explain the rationale**
of why you are doing so in your `remarks.md` file. Even if you do explain this in your `remarks.md` file
your submission may still be rejected.
**`|`** You may check your code prior to submission by giving the filename
as a command like argument to the `iocccsize(1)` tool. For example:
``` <!---sh-->
./iocccsize prog.c
```
<div id="rule2b">
## Rule 2b
</div>
**`|`** When your program source is fed as input to the current IOCCC size
tool, and the IOCCC size tool `-i` command line option is used, the
value printed **shall not exceed 2503**.
**`|`** When the filename of your program source is given as a command line argument to the latest version
of the official IOCCC size tool (hereby referred to as `iocccsize(1)`), the value printed **should not exceed 2503**.
**`|`** The source to the current IOCCC size tool is found in the
[mkiocccentry tool repo](https://github.com/ioccc-src/mkiocccentry). If you use
the `mkiocccentry` tool (which we **STRONGLY recommend you do**) it will invoke
this tool before packaging your entry for submission.
**`|`** The source to `iocccsize(1)` may be found in the
[mkiocccentry tool repo](https://github.com/ioccc-src/mkiocccentry).
**`|`** If you use the `mkiocccentry(1)` tool, which we **STRONGLY recommend you use**,
then `mkiocccentry(1)` will invoke `iocccsize(1)` before packaging your entry for submission.
**`|`** The `mkiocccentry(1)` tool will give you the option of overriding the [Rule 2b](#rule2b) warning.
Overriding a [Rule 2b](#rule2b) warning carries a **fair amount of risk** that your submission
will be **rejected**. Be sure to consult the [IOCCC guidelines](guidelines.html)
ahead of time if you plan to override the [Rule 2b](#rule2b) warning.
**`|`** If you do override the [Rule 2b](#rule2b) warning from the `mkiocccentry(1)` tool,
or otherwise plan to violate [Rule 2a](#rule2b), then you **must clearly explain the rationale**
of why you are doing so in your `remarks.md` file. Even if you do explain this in your `remarks.md` file
your submission may still be rejected.
**`|`** You may check your code prior to submission by giving the filename
as a command like argument to the `iocccsize(1)` tool. For example:
``` <!---sh-->
./iocccsize prog.c
```
<div id="rule3">
## Rule 3
@@ -387,8 +424,11 @@ Do not assume that `.` (the current directory) is in the `$PATH`.
Use a shell command syntax that is compatible with bash.
Assume that commands commonly found in POSIX-like / Linux-like systems
are available in the search path.
**`|`** Assume that commands commonly found in [Single UNIX
Specification](https://en.wikipedia.org/wiki/Single_UNIX_Specification)
environments and systems that conform to the [Single UNIX
Specification](https://en.wikipedia.org/wiki/Single_UNIX_Specification) are
available in the `$PATH` search path.
Do not assume any particular given value of `${CFLAGS}` or other
commonly used make variables. In other words you **MUST** specify the `CFLAGS`