From 8f5f941e637af45ab9b15db916ad928b6c670e49 Mon Sep 17 00:00:00 2001 From: Cody Boone Ferguson <53008573+xexyl@users.noreply.github.com> Date: Tue, 11 Jun 2024 12:07:14 -0700 Subject: [PATCH] Check links/formatting in remaining next/ files Some links were fixed. For instance instead of index.html#enter it's now the relevant FAQ. A markdown link was broken so that it did not create a link at all. Some formatting was updated mostly to make points bold or in code block (if it's going to be html it might as well especially as they are important). And although there were some typo fixes there still are some typos in there. If you don't know why that is see the FAQ 1.0: How did the IOCCC get started?. :-) Besides much will be changed in these files by the judges and the purpose of this commit was to make sure links were valid and that the files are rendered okay, not to try and change the rules (although I did update the IOCCC email and make it the 28th IOCCC and fix the judges [list] .. to make a reference to something recent :-) ). This commit means that the files under next/ have all been checked. As usual we all anticipate things to change but some things that were outdated were corrected (or they were at least partially corrected like referring to the mkiocccentry repo) to help out a bit. --- next/guidelines.html | 118 +++++++++++++++++++------------------ next/guidelines.md | 134 ++++++++++++++++++++----------------------- next/rules.html | 122 +++++++++++++++++++++++---------------- next/rules.md | 125 +++++++++++++++++++++++----------------- 4 files changed, 267 insertions(+), 232 deletions(-) diff --git a/next/guidelines.html b/next/guidelines.html index 762ccb1c9..4d62b6f5a 100644 --- a/next/guidelines.html +++ b/next/guidelines.html @@ -384,7 +384,7 @@

WARNING: These guidelines are OUT OF DATE

-

They are a very tentative proposal for the next IOCCC +

These guidelines are a very tentative proposal for the next IOCCC that is VERY LIKELY to be updated before the next IOCCC. They are are provided as a very tentative hint at what might be used in a future IOCCC.

@@ -396,46 +396,48 @@ might be used in a future IOCCC.

@IOCCC mastodon feed for information about future IOCCC openings.

-

27th International Obfuscated C Code Contest Official Guidelines

+

28th International Obfuscated C Code Contest Official Guidelines

Copyright © 2024 Leonid A. Broukhis, Landon Curt Noll.

All Rights Reserved. Permission for personal, education or non-profit use is granted provided this this copyright and notice are included in its entirety and remains unaltered. All other uses must receive prior permission in -writing from the contest judges.

+writing by contacting the judges.

Guidelines version

| This guidelines file is version 2023-04-04-v28.

-

IMPORTANT: Be sure to read the IOCCC rules.

+

IMPORTANT: Be SURE to read the IOCCC rules.

Change marks

| ← Lines that start with this symbol indicate a change from the previous IOCCC

-

Most lines (we sometimes make mistakes) that were modified start the | symbol.

+

Most lines (we sometimes make mistakes) that were modified since the previous +IOCCC start with the | symbol.

ABOUT THIS FILE:

-

This file contains guidelines intended to help people who wish to -submit entries to the International Obfuscated C Code Contest (IOCCC).

-

This is not the IOCCC rules, though it does contain comments about -them. The guidelines should be viewed as hints and suggestions. +

This file contains guidelines intended to help people who wish to +submit entries to the International Obfuscated C Code Contest +(IOCCC).

+

These are not the IOCCC rules, though it does contain comments about +them. The guidelines should be viewed as hints and suggestions. Entries that violate the guidelines but remain within the rules are allowed. Even so, you are safer if you remain within the guidelines.

-

You should read the current IOCCC rules, prior to submitting entries. +

You should read the current IOCCC rules, prior to submitting entries. The rules are typically sent out with these guidelines.

WHAT’S NEW IN 2019/2020

| This IOCCC runs from 2019-Dec-26 06:01:41 UTC to 2020-Mar-15 06:26:49 UTC.

| The reason for the times of day are so that key IOCCC events occur during UTC | “prime time”. Do you understand why we factored this into the rules and | guidelines? :-)

-

Until the start of this IOCCC, these rules, guidelines and iocccsize.c tool -should be considered provisional BETA versions and may be adjusted -at any time.

+

Until the start of this IOCCC, these rules, guidelines and iocccsize.c +(contained in the mkiocccentry +toolkit) +tool should be considered provisional BETA versions and may be +adjusted AT ANY TIME.

| Even though the contest will start in 2019, because the contest will close | in 2020, URLs, subject lines, and contest related email addresses use 2019.

-

The IOCCC submission URL:

-
    https://submit.ioccc.org/
+

The IOCCC submission URL is https://submit.ioccc.org/.

| The submit URL should be active on or slightly before 2020-Jan-15 12:21:37 UTC.

Please wait to submit your entries until after that time.

-

The official rules, guidelines and iocccsize.c tool will be available +

The official rules, guidelines and iocccsize.c (invoked by the mkiocccentry) tool will be available on the official IOCCC website on or slightly before start of this IOCCC. -Please check the IOCCC website “How to enter” link:

-
    https://www.ioccc.org/index.html#enter
-

on or after the start of this IOCCC to be sure you are using the correct +Please check the IOCCC FAQ How to submit. +on or after the start of this IOCCC to be sure you are using the correct versions of these items before using the IOCCC entry submission URL.

HINTS AND SUGGESTIONS:

You are encouraged to examine the winners of previous contests. See @@ -568,9 +570,11 @@ and enjoy your entry.

So try to ensure that your entry compiles warning free. If possible, to compile compile your code using:

    -Wall -Wextra -pedantic
-

For compilers, such as clang, that have the -Weverything option, try +

For compilers, such as clang, that have the -Weverything option, try to make your code compile warning free using:

    -Wall -Wextra -Weverything -pedantic
+

.. though see Why do Makefiles use -Weverything with +clang? in 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 @@ -588,7 +592,7 @@ except in one small part (ISO/IEC 9899:2011) where they might not truly understand the implications of such words.

    http://hitchhikers.wikia.com/wiki/Belgium
     http://www.bezem.de/pdf/ReservedWordsInC.pdf
-

DO NOT assume that we will use gcc to compile your program. +

DO NOT assume that we will use gcc to compile your program. We will first try to compile your program using Clang.

It is much better to not use any obscure compiler flags if you can help it. We want to discourage the use of obscure compiler @@ -602,7 +606,7 @@ of nested functions such as:

| please_do_not_submit_this(); }

This is because such nested functions often requires one to compile with -a flag such as -fnested-functions that is not found on some compilers.

+a flag such as -fnested-functions that is not found on some compilers.

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 required by a C standard that are @@ -610,23 +614,23 @@ actually implemented in commonly used C compilers. Sorry!

| We prefer programs that do not require a fish license: crayons and | cat detector vans not withstanding.

If your entry uses functions that have a variable number of -arguments, be careful. Systems implement va_list as a wide variety -of ways. Because of this, a number of operations using va_list are +arguments, be careful. Systems implement va_list as a wide variety +of ways. Because of this, a number of operations using va_list are not portable and must not be used:

-

In particular, do not treat va_list variables as if they were a char **’s.

-

Avoid using <varargs.h>. Use <stdarg.h> instead.

+

In particular, do not treat va_list variables as if they were a char **s.

+

Avoid using varargs.h. Use stdarg.h instead.

On 28 January 2007, the Judges rescinded the requirement that the -’#” in a C preprocessor directive must be the 1st non-whitespace octet.

-

The exit() function returns void. Some broken systems have exit() -return int, your entry should assume that exit() returns a void.

+# in a C preprocessor directive must be the 1st non-whitespace octet.

+

The exit(3) function returns void. Some broken systems have exit(3) +return int, your entry should assume that exit(3) returns a void.

| This guideline has a change mark at the very start of this line.

Small programs are best when they are short, obscure and concise. While such programs are not as complex as other winners, they do @@ -697,13 +701,13 @@ operating systems (i.e., Linux, GNU Hurd, BSD, Unix, etc.).

There are at least zero judges who think that Fideism has little or nothing to do with the IOCCC judging process.

Don’t forget that the building of your program should be done -without human intervention. So don’t do things such as:

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

However, you can do something cute such as making your program -do something dumb (or cute) when it is built ‘automatically’. And +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 use the build instructions:

    prog: prog.c
@@ -713,14 +717,14 @@ For example, one could use the build instructions:

 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 to get around the size limit.
+
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
 large data files to get around the source code size limit.

-
We do not recommend submitting systemd source code to the IOCCC,
+
We do not recommend submitting systemd source code to the IOCCC,
 if nothing else because that code is likely to exceed the source code
 size limit. This isn’t to say that another highly compact and obfuscated
-replacement of init would not be an interesting submission.

+replacement of init would not be an interesting submission.

 
Did we remember to indicate that programs that blatantly use
 some complex state machine to do something simple are boring?
 We think we did. :-)

@@ -732,7 +736,7 @@ 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 entry. See the rules for details.

 
We suggest that you avoid trying for the ‘smallest self-replicating’
-source. The smallest, a zero byte entry, won in 1994.

+source. The smallest, a zero byte entry, won in 1994.

 
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.

@@ -813,7 +817,7 @@ 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”.

-
We dislike C code with trailing control-M’s (r \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
@@ -832,7 +836,7 @@ Instead of unescaped octets, you should use or escapes:

 
It is a very good idea to, in your remarks 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!

+otherwise overlook. <<– Hint!

 
Anyone can format their code into a dense blob. A really clever
 author will try format their entry using a “normal” formatting style
 such that at first glance (if you squint and don’t look at the details)
@@ -941,11 +945,11 @@ sales, product management an even from customers themselves on a
 all too regular basis. This is one of the reasons why the rules and
 guidelines are written in obfuscated form.

 
JUDGING PROCESS:

-
Entries are judged by Leonid A. Broukhis, Simon Cooper, Landon Curt Noll.

+
Entries are judged by Leonid A. Broukhis and Landon Curt Noll.

 
Each entry submitted is given a random id number and subdirectory. The
 entry files including, but not limited to prog.c, Makefile (that we
 form from around your “how to build” information), as well as any
-data files that you submit are all placed under their own directory.
+data files that you submit are all placed under their own directory
 stored and judged from this directory.

 
Any information about the authors is not read by the judges until
 the judging process is complete, and then only from entries that have
@@ -959,7 +963,7 @@ about the others. However we consider this to be simply circumstantial
 and outside the scope of the above paragraph.

 
Some people, in the past, have attempted to obfuscate their identity by
 including comments of famous Internet personalities such as Peter Honeyman
-(http://www.citi.umich.edu/u/honey/). The judges are on to this
+(http://www.citi.umich.edu/u/honey/). The judges are on to this
 trick and therefore consider any obfuscated source or data file
 claiming to be from Honeyman to not be form Honeyman. This of course
 creates an interesting paradox known as the “obfuscated Peter Honeyman
@@ -972,7 +976,7 @@ 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
 exempt” not withstanding.

@@ -985,7 +989,7 @@ Because the main ‘prize’ of winning is being announced, we make all
 attempts to send non-winners into oblivion. We remove all non-winning
 files, and shred all related paper. By tradition, we do not even
 reveal the number of entries that we received.

-
During the judging process. a process that spans multiple sessions
+
During the judging process, a process that spans multiple sessions
 over a few weeks, post general updates from our @IOCCC twitter account.

 
Once we have selected the winners, for each category we will tweet: