diff --git a/next/guidelines.html b/next/guidelines.html index 066eb705c..39050d632 100644 --- a/next/guidelines.html +++ b/next/guidelines.html @@ -461,7 +461,7 @@ writing by contacting the judges.

-These IOCCC guidelines are version 28.41 2025-03-03. +These IOCCC guidelines are version 28.42 2025-03-03.

The markdown form of these guidelines submit server might be offline and/or

The submit server, in accordance with Rule 17, -places a limit of 3999971 octets on the size of your upload. +places a limit of 3999971 bytes on the size of your upload. +

+

+The some the byte lengths of all files, after the xz compressed tarball is un-tarred, +must not exceed 27651*1024 bytes.

Submissions are uploaded as a single xz compressed tarball. @@ -717,9 +721,9 @@ The IOCCC size tool algorithm can be summarized as follows:

The size tool counts most C reserved words (keyword, secondary, and selected -preprocessor keywords) as 1. The size tool counts all other octets as 1 +preprocessor keywords) as 1. The size tool counts all other bytes as 1 excluding ASCII whitespace, and excluding any ‘;’, ‘{’ or ‘}’ followed by -ASCII whitespace, and excluding any ‘;’, ‘{’ or ‘}’ octet immediately +ASCII whitespace, and excluding any ‘;’, ‘{’ or ‘}’ byte immediately before the end of file.

ASCII whitespace includes ASCII tab, ASCII space, ASCII newline, @@ -791,15 +795,24 @@ Although we are in an age where AI/LLM can create code, we don’t want to stop anyone from using any tools they like when they’re working on their submissions.

-The IOCCC has a rich history of remarkable winning entries created -by authors who skillfully employed various techniques such as code generators, code analysis tools, machine learning tools, natural language models, code copilot tools, so-called AI services, -and/or large language models. Although it is NOT required use such +large language models, etc. Although it is NOT required use such things to develop your submission, you are free to continue to create their submissions using such tools.

+The IOCCC has a rich history of remarkable winning entries created by +authors who skillfully employed various techniques to develop their code. +While it is NOT required, you are allowed to use tools to develop +and test your submission. These tools may include, but are not limited +to code generators, code analysis tools, static code analysis tools, +runtime analysis tools, machine learning tools, natural language models, +code copilot tools, so-called AI services, large language models, etc. +If you do make use of such tools, then we ENCOURAGE you to describe +how you used such tools in your remarks.md file. +

+

If you do make use of code generator, code analysis tool, machine learning tool, natural language model, code copilot tool, a so-called AI service, and/or large language models we ENCOURAGE you to describe how you used @@ -1668,7 +1681,7 @@ tarball containing a number of extra files may be needed. Such a need for a tarball MUST be explained in the remarks.md file.

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

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

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

@@ -1688,7 +1701,7 @@ explain to the Walrus why our seas are boiling hot, the question of whether pigs have wings is likely to remain a debatable point to most.

One line programs should be short one line programs: say around 80 to 120 -octets long. Going well beyond 120 octets is a bit too long to be called +bytes long. Going well beyond 120 bytes is a bit too long to be called a one-liner in our vague opinion.

We tend to DISLIKE programs that: