From 93081c8f5d2a80d6bb243afe94722a334caead4a Mon Sep 17 00:00:00 2001 From: Landon Curt Noll Date: Mon, 24 Jun 2024 18:09:16 -0700 Subject: [PATCH] improvements to Rule 2 in rules and guidelines --- next/guidelines.html | 126 +++++++++++++++++++++---------------------- next/guidelines.md | 126 +++++++++++++++++++++---------------------- next/rules.html | 49 +++++++++++++---- next/rules.md | 62 +++++++++++++++++---- 4 files changed, 214 insertions(+), 149 deletions(-) diff --git a/next/guidelines.html b/next/guidelines.html index e73b27da9..2f2a9619d 100644 --- a/next/guidelines.html +++ b/next/guidelines.html @@ -483,7 +483,7 @@ to attempt to exploit them. We will award ‘Worst abuse of the rules 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 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 @@ -491,7 +491,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, world!” really really, and we do mean really, do need to be more creative.

@@ -503,17 +503,17 @@ misleading comments and variable names might be a good start.

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

-

| Rule 2 (the size rule) refers to the use of the IOCCC size tool called iocccsize.

-

| See the mkiocccentry toolkit for the iocccsize tool.

-

| To further clarify Rule 2, we subdivided it into two parts, 2a and 2b.

-

| The overall size limit (see Rule 2a) on prog.c is now 4993 bytes

+

| Rule 2 (the size rule) refers to the use of the IOCCC size tool called iocccsize(1).

+

| See the mkiocccentry toolkit for the iocccsize(1) tool.

+

| To further clarify Rule 2, we subdivided it into two parts, 2a and 2b.

+

| The overall size limit (see Rule 2a) on prog.c is now 4993 bytes.

| Your entry must satisfy BOTH the maximum size Rule 2a AND your entry must satisfy the IOCCC size tool Rule 2b.

This tool imposes a 2nd limit on C code size (see Rule 2a. To check your code against the 2nd limit of Rule 2, use the -i command line option. For example:

-
    ./iocccsize -i < prog.c
-

The IOCCC size tool, when using the -i option, may be summarized as:

+
    ./iocccsize prog.c
+

| The IOCCC size tool algorithm may be summarized as follows:

    The size tool counts most C reserved words (keyword, secondary,
     and selected preprocessor keywords) as 1.  The size tool counts all
     other octets as 1 excluding ASCII whitespace, and excluding any
@@ -555,7 +555,7 @@ both clang and gcc
 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:

 
    #define d define
     #d foo             /* <-- don't expect this to turn into #define foo */

 
When declaring local or global variables, you should declare the type:

@@ -567,10 +567,10 @@ c11 (formerly C1X) C compiler (ISO/IEC 9899:2011).

 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:

 
    -Wall -Wextra -pedantic

@@ -581,11 +581,11 @@ to make your code compile warning free using:

 the FAQ.

 
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:

 
    -O3 -std=c11

 
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.

 
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)
    
+| * dump core or have compiler warnings (it is OK only if you warn us in your ‘remark,md’ file)
    
+| * won’t compile or run a Single UNIX Specification environment
    • 
+
  • depend on a utility or application not normally found systems that conform to the Single UNIX Specification
    • 
+
  • abuse the build file to get around the size limit
    
+| * obfuscate by use of ANSI trigraphs
    
+| * are larger than they need to be
    
+| * have more lines than they need to have
    
+| * are “blob-ier” (just a pile of unformatted C code) than they need to be
    • 
+
  • are rather similar to previous winners :-(
    • 
+
  • are identical to previous losers :-)
    • 
 
  • that mandate the exclusive 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 environment Therefore do not assume the system has a
 windows.h include file:

-
    #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
 ‘Best one liner’ category, we suggest that you format your program
 in a more creative way than simply forming excessively long lines.

@@ -697,9 +693,10 @@ bytes of -Ds in order to try and squeeze the source under the size
 
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 environments
+and systems that conform to the Single UNIX Specification.

+
| You may compile and use your own programs. If you do, try to build and execute
 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.

@@ -721,13 +718,13 @@ For example, one could use the build instructions:

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

 
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;

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

 
    char *T = "So many primes, so little time!";
     ...
     T[14] = ';';

@@ -776,13 +773,13 @@ software that is not in wide spread use.

 
| However, do you know how to play fizzbin?
 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
 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:

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

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!

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

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.

@@ -876,8 +873,8 @@ interesting than simply implementing the IOCCC size tool algorithm.

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:

    -arch i386
@@ -885,8 +882,8 @@ following compiler flag:

    prog: prog.c
         ${CC} prog.c -arch i386 -o prog

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:

    This entry factors values up 2305567963945518424753102147331756070.
     Attempting to factor larger values will produce unpredictable results.
@@ -913,10 +910,11 @@ and state:

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

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

ABUSING THE RULES:

Legal abuse of the IOCCC rules is somewhat encouraged. Legal rule abuse @@ -933,8 +931,8 @@ disqualified. RULE ABUSE CARRIES A CERTAIN LEVEL OF RISK!IOCCC rules and one that does.

-

If you intend to abuse the IOCCC rules, 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, 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. That is, you must plead your case as to why your entry is valid. Humor and/or creativity help plead a case.

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?

-

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:

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.

A reading consists of a number of actions: