Restore Makefile section in guidelines

Other fixes were made as well, including in the rules. More work has to be done still.
2025-11-29 10:15:47 -08:00
1 parent 0ba38856aa
commit 4939cda9e1
@@ -452,36 +452,15 @@
 <!-- START: this line starts content for HTML phase 21 by: bin/pandoc-wrapper.sh via bin/md2html.sh -->

 <!-- BEFORE: 1st line of markdown file: next/guidelines.md -->
-<!-- START: this line starts content from: inc/guidelines.closed.hdr -->
-<h1 id="the-ioccc-is-closed">The IOCCC is closed</h1>
-<p>The IOCCC is <strong>NOT</strong> accepting new submissions at this time. See the
-<a href="../years.html">IOCCC winning entries page</a> for the entries that have won the
-IOCCC in the past.</p>
-<p>These guidelines are a <strong>TENTATIVE proposal</strong> for the next IOCCC
-and are <strong>likely be to be updated</strong> before the next IOCCC.</p>
-<p>See our
-FAQ on “<a href="../faq.html#feedback">rules, guidelines, tools feedback</a>”
-as well as our
-FAQ on “<a href="../faq.html#question">about asking questions</a>”
-about these guidelines. You might also find the FAQ in general useful, especially the
-FAQ on “<a href="../quick-start.html#enter">how to enter the IOCCC</a>”.</p>
-<p>Watch both <a href="../status.html">the IOCCC status page</a> and the
-<a href="https://fosstodon.org/@ioccc"><span class="citation" data-cites="IOCCC">@IOCCC</span> mastodon feed</a> for information about
-future IOCCC openings.</p>
-<p><strong>HINT to mastodon users</strong>: You may wish to refresh the <a href="https://fosstodon.org/@ioccc"><span class="citation" data-cites="IOCCC">@IOCCC</span>
-mastodon feed</a> page and/or mastodon
-app from time to time to view IOCCC mastodon updates.</p>
-<!-- END: the next line ends content from: inc/guidelines.closed.hdr -->
-<!-- This is the last line modified by the tool: bin/gen-status.sh -->
 <h1 id="th-international-obfuscated-c-code-contest-official-guidelines">29th International Obfuscated C Code Contest Official Guidelines</h1>
 <p class="leftbar">
 Copyright © 2025 Leonid A. Broukhis and Landon Curt Noll.
 </p>
 <p>All Rights Reserved. Permission for personal, education or non-profit use is
-granted provided this this copyright and notice are included in its entirety
+granted provided this copyright and notice are included in its entirety
 and remains unaltered. All other uses must receive prior permission in
 writing by <a href="../contact.html">contacting the judges</a>.</p>
-<h1 id="ioccc-guidelines-version">IOCCC Guidelines version</h1>
+<h1 id="guidelines-version">Guidelines Version</h1>
 <p class="leftbar">
 These IOCCC guidelines are version <strong>29.01 2025-11-29</strong>.
 </p>
@@ -535,7 +514,7 @@ because of the <code>iocccsize(1)</code> algorithm.</p>
 <p>Jump to: <a href="#">top</a></p>
 <div id="guideline3">
 <div id="guideline-3---register">
-<h1 id="guidelines-for-rule-3---register-for-the-contest">Guidelines for <a href="rules.html#rule3-register">Rule 3 - Register for the contest</a></h1>
+<h1 id="guidelines-for-rule-3---register-for-the-ioccc">Guidelines for <a href="rules.html#rule3-register">Rule 3 - Register for the IOCCC</a></h1>
 </div>
 </div>
 <p>See FAQ on “<a href="../faq.html#author_handle_faq">What is an author handle?</a>”.</p>
@@ -557,10 +536,10 @@ because of the <code>iocccsize(1)</code> algorithm.</p>
 <li>Etc.</li>
 </ul>
 <p>The IOCCC has a rich history of remarkable winning entries created by
-authors who skillfully employed various techniques to develop their code.</p>
-<p>If you do make use of such tools or services, then we <strong>ENCOURAGE you to describe
-how you used such tools</strong> in your <code>remarks.md</code> file.</p>
-<p>In short: You created it, you own it, and its an original work, or you have explicit permission.</p>
+authors who skillfully employed various techniques to develop their code.
+If you do make use of such tools or services, then we <strong>ENCOURAGE you to
+describe how you used such tools</strong> in your <code>remarks.md</code> file.</p>
+<p>In short: You created it, you own it, its an original work, or you have explicit permission to the work.</p>
 <p>See FAQ on “<a href="../faq.html#ai">May I use AI, LLM, Virtual coding assistants, or similar tools to write my submission?</a>”.</p>
 <p>Jump to: <a href="#">top</a></p>
 <div id="guideline11">
@@ -568,40 +547,36 @@ how you used such tools</strong> in your <code>remarks.md</code> file.</p>
 <h1 id="guidelines-for-rule-11---legal-rule-abuse">Guidelines for <a href="rules.html#rule11-legal-rule-abuse">Rule 11 - Legal rule abuse</a></h1>
 </div>
 </div>
-<p>We try to avoid limiting creativity in our <a href="rules.html">IOCCC rules</a> so
-we leave the contest open for creative rule interpretation.</p>
 <p>We do realize that there are holes in the <a href="rules.html">IOCCC rules</a>, and invite
-submitters to attempt to exploit them.</p>
+submitters to attempt to apply creative rule interpretation. A rule abuse though, even
+if not rewarded, may result in a subsequent rule change for future contests.</p>
 <p>We sometime award ‘<strong>Best abuse of the rules</strong>’ or ‘<strong>Worst abuse of the rules</strong>’,
 or some variation, to a submission that creatively attempts to exploit a holes in the
 <a href="rules.html">IOCCC rules</a>.</p>
-<p>When we do need to plug a hole in the <a href="rules.html">IOCCC rules</a> or
-<a href="guidelines.html">IOCCC guidelines</a>, we will attempt to use a very small plug,
+<p>When we do need to plug a hole in the <a href="rules.html">IOCCC rules</a>
+or <a href="guidelines.html">IOCCC guidelines</a>, we will attempt to use a very small plug,
 if not smaller.</p>
 <p>Or, maybe not. :-)</p>
-<p>Legal abuse of the <a href="rules.html">IOCCC rules</a> is somewhat encouraged. Legal rule abuse
-may involve, but is not limited to, doing things that are technically allowed by
-the <a href="rules.html">IOCCC rules</a> and yet do not fit the spirit of what we intended to be
-submitted.</p>
-<p>Legal rule abuse is encouraged to help promote creativity. Rule abuse
-submissions, regardless of if they receive an award, result in changes to
-the next year’s <a href="rules.html">IOCCC rules</a> and <a href="guidelines.html">IOCCC guidelines</a>.</p>
-<p>Legal abuse of the <a href="rules.html">IOCCC rules</a> is <strong>NOT</strong> an invitation to violate the
-<a href="rules.html">IOCCC rules</a>. A submission that violates the <a href="rules.html">rules</a> in the
-opinion of the <a href="../judges.html">IOCCC judges</a>, <strong>WILL</strong> be
-disqualified. <strong><em>RULE ABUSE CARRIES A CERTAIN LEVEL OF RISK!</em></strong> If you
-have a submission 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, making sure to note in the one that does not abuse the rules that this is
-another version, so that the judges do not assume you uploaded it by mistake.</p>
+<p>Legal rule abuse may involve, but is not limited to, doing things that are
+technically allowed by the <a href="rules.html">IOCCC rules</a> and yet do not fit the spirit of what
+we intended to be submitted.</p>
+<p>Legal abuse of the <a href="rules.html">IOCCC rules</a> is <strong>NOT</strong> an invitation to violate
+the <a href="rules.html">IOCCC rules</a> (especailly <a href="./rules.html#rule-17---packaging">Rule 17 -
+Packaging</a> ). A submission that violates the
+<a href="rules.html">rules</a> in the opinion of the <a href="../judges.html">IOCCC judges</a>,
+<strong>WILL</strong> be disqualified. <strong><em>RULE ABUSE CARRIES A CERTAIN LEVEL OF RISK!</em></strong></p>
 <p>If you intend to abuse the <a href="rules.html">IOCCC rules</a>,
-indicate so in your <code>remarks.md</code> file. You <strong>MUST</strong> try to justify
+indicate so in your <code>remarks.md</code> file. You <strong>MUST</strong> try to justify, plead, beg,
 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 submission is valid. Humor and/or creativity help plead a case.
+<a href="rules.html">IOCCC rules</a>. Humor or creativity help plead a case.
 As there is no guarantee that you will succeed, you might consider
 submitting an alternate version that conforms to the
 <a href="rules.html">IOCCC rules</a>.</p>
+<p>If you have a submission 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, making sure to note in the one that does not abuse the rules that
+this is another version, so that the judges do not assume you uploaded it by
+mistake.</p>
 <p>If you do bypass the <code>mkiocccentry(1)</code> warnings about
 <a href="rules.html#rule-2a-gross-size">Rule 2a - Gross Size</a>
 and/or about
@@ -611,14 +586,11 @@ rule and submit a submission anyway, you <strong>MUST</strong> try to justify wh
 <a href="../judges.html">IOCCC judges</a> should not reject your submission due to a rule
 violation, and you would be wise to do this towards the top of your <code>remarks.md</code>
 file.</p>
-<p>Abusing the web submission procedure tends to annoy us more
-than amuse us. Spend your creative energy on content of your
-submission rather than on the submission process itself.</p>
 <p>We are often asked why the contest <a href="rules.html">IOCCC rules</a> and <a href="guidelines.html">IOCCC
-guidelines</a> seem strange or contain mistakes, flaws or
-grammatical errors. One reason is that we sometimes make genuine mistakes. But
-in many cases such problems, flaws or areas of confusion are deliberate.
-Changes to <a href="rules.html">IOCCC rules</a> and <a href="guidelines.html">IOCCC guidelines</a> in
+guidelines</a> seem strange or contain mistakes, flaws, or
+grammatical errors. One reason is that we sometimes make genuine mistakes, but
+in many cases such problems, flaws or areas of confusion are deliberate.</p>
+<p>Changes to <a href="rules.html">IOCCC rules</a> and <a href="guidelines.html">IOCCC guidelines</a> in
 response to rule abuses, are done in a minimal fashion. Often we will
 deliberately leave behind holes (or introduce new ones) so that future rule
 abuse can continue. A clever author should be able to read them and “drive a
@@ -630,7 +602,7 @@ are only part of the overall contest. Even so, one might think the
 contest <a href="rules.html">IOCCC rules</a> and <a href="guidelines.html">IOCCC guidelines</a> process as a parody
 of the sometimes tragic mismatch between what a customer (or marketing) wants
 and what engineering delivers. Real programmers must face obfuscated and
-sometimes conflicting specifications and requirements from marketing, sales,
+sometimes conflicting, balloning specifications, and requirements from marketing, sales,
 product management and even from customers themselves on an all too regular basis.
 This is one of the reasons why the <a href="rules.html">IOCCC rules</a> and
 <a href="guidelines.html">IOCCC guidelines</a> are written in obfuscated form.</p>
@@ -640,13 +612,13 @@ This is one of the reasons why the <a href="rules.html">IOCCC rules</a> and
 <h1 id="guidelines-for-rule-15---gnu-makefile">Guidelines for <a href="rules.html#rule15-gnu-makefile">Rule 15 - GNU Makefile</a></h1>
 </div>
 </div>
-<p>You may use git, or services such as <a href="https://www.github.com">GitHub</a>
+<p>You may use <code>git,</code> or services such as <a href="https://www.github.com">GitHub</a>
 to develop and maintain your submission. However, we <strong>DISLIKE</strong>
 submissions that <strong>require</strong> such services in order to build/compile your submission.</p>
 <p>Submissions will be judged in an environment that has no <strong>IDE</strong>.
 Any submission that fails to compile/build because it requires
 an <strong>IDE</strong> will be rejected.</p>
-<p>We will use the <code>make(1)</code> tool, your <code>Makefile</code>, as well as tools found in the
+<p>We will use the <code>GNU make(1)</code> tool, your <code>Makefile</code>, as well as tools found in the
 <a href="https://en.wikipedia.org/wiki/Single_UNIX_Specification">Single UNIX Specification</a>
 environments, and commonly found on systems that reasonably conform to the
 <a href="https://en.wikipedia.org/wiki/Single_UNIX_Specification">Single UNIX Specification</a>
@@ -664,7 +636,7 @@ course.</p>
 </div>
 <p>We <strong>STRONGLY</strong> recommend you <strong>do</strong> install the most recent release of
 <a href="https://github.com/ioccc-src/mkiocccentry">mkiocccentry toolkit</a>
-as use of using older versions of the mkiocccentry toolkit to are <strong>HIGHLY LIKELY</strong> to be <strong>REJECTED</strong>!</p>
+As use of using older versions of the mkiocccentry toolkit to are <strong>HIGHLY LIKELY</strong> to be <strong>REJECTED</strong>!</p>
 <p>If you submit your own JSON files (other than <code>.auth.json</code> and
 <code>.info.json</code>) then they do <strong>NOT</strong> have to be valid JSON.</p>
 <p>However, if you do provide invalid JSON files, <strong>PLEASE</strong>
@@ -714,10 +686,12 @@ FAQ on “<a href="../faq.html#makefile_details">What are the detailed recommend
 FAQ on “<a href="../faq.html#rule17">What are the details behind Rule 17 - Use mkiocccentry?</a>”.</p>
 <p>Jump to: <a href="#">top</a></p>
 <div id="mkiocccentry">
+
+</div>
 <div id="mkiocccentry_toolkit">
+
+</div>
 <h1 id="guidelines-for-the-mkiocccentry-toolkit">Guidelines for the mkiocccentry toolkit</h1>
-</div>
-</div>
 <p>The <a href="https://submit.ioccc.org">IOCCC submit server</a>, and related services
 use the <strong>most recent version</strong> of the
 <a href="https://github.com/ioccc-src/mkiocccentry">mkiocccentry toolkit</a>:
@@ -725,10 +699,10 @@ submissions that package using older versions of the
 <a href="https://github.com/ioccc-src/mkiocccentry">mkiocccentry toolkit</a>
 are <strong>LIKELY</strong> to be <strong>REJECTED</strong>!</p>
 <p>You <strong>REALLY SHOULD</strong> use the latest <a href="https://github.com/ioccc-src/mkiocccentry">mkiocccentry toolkit</a>
+are <strong>LIKELY</strong> to be <strong>REJECTED</strong>! So you <strong>REALLY SHOULD</strong> use the latest <a href="https://github.com/ioccc-src/mkiocccentry">mkiocccentry toolkit</a>
 to package your own submission.</p>
 <p>The <code>mkiocccentry(1)</code> tool runs a number of checks by way of these
-<a href="https://github.com/ioccc-src/mkiocccentry">mkiocccentry toolkit</a>
-tools:</p>
+<a href="https://github.com/ioccc-src/mkiocccentry">mkiocccentry toolkit</a> tools:</p>
 <ul>
 <li>iocccsize(1)</li>
 <li>txzchk(1)</li>
@@ -736,42 +710,47 @@ tools:</p>
 <li>chksubmit(1)</li>
 <li>chkentry(1)</li>
 </ul>
-<p>Do <strong>NOT</strong> use <code>txzchk(1)</code> command line options that are labeled “<strong>for TESTING purposes</strong>”
-in the <code>txzchk(1)</code> man page.</p>
+<p>Do <strong>NOT</strong> use <code>txzchk(1)</code> or <code>fnamchk(1)</code> command line options that are labeled
+“<strong>for TESTING purposes</strong>” in their respective man pages.</p>
 <p>Do <strong>NOT</strong> use <code>fnamchk(1)</code> command line options that are labeled “<strong>for TESTING purposes</strong>”
 in the <code>fnamchk(1)</code> man page.</p>
 <p>Do <strong>NOT</strong> use <code>chkentry(1)</code> command line options that are labeled “<strong>for the use by the IOCCC judges only</strong>”
-in the <code>chksubmit(1)</code> (or <code>chkentry(1)</code>) man page(s).</p>
+in the <code>chksubmit(1)</code> (or <code>chkentry(1)</code>) man page(s).
+Similarly do <strong>NOT</strong> use <code>chkentry(1)</code> command line options marked “<strong>for the use
+by the IOCCC judges only</strong>” in the <code>chkentry(1)</code> man page.</p>
 <p>To view <a href="https://github.com/ioccc-src/mkiocccentry">mkiocccentry toolkit</a> man pages,
 while your current directory is the top of the source tree:</p>
-<pre><code>    man soup/man/man1/mkiocccentry.1
-    man soup/man/man1/iocccsize.1
-    man soup/man/man1/txzchk.1
-    man test_ioccc/man/man1/fnamchk.1
-    man soup/man/man1/chksubmit.1
-    man soup/man/man1/chkentry.1</code></pre>
+<pre><code>man soup/man/man1/mkiocccentry.1
+man soup/man/man1/iocccsize.1
+man soup/man/man1/txzchk.1
+man test_ioccc/man/man1/fnamchk.1
+man soup/man/man1/chksubmit.1
+man soup/man/man1/chkentry.1</code></pre>
 <p>The above <code>man(1)</code> commands will show the toolkit man pages without having to install them first.</p>
 <p>So that you do not have to repeatedly answer all the <code>mkiocccentry(1)</code> questions,
 use <code>mkiocccentry -a answers ...</code> to create a file containing the answers you first give,
-that will allow you to later use <code>mkiocccentry -i answers ...</code> to reuse those same answers.</p>
+so later enter <code>mkiocccentry -i answers ...</code> to reuse those same answers.</p>
 <p>The <code>mkiocccentry -A answers ...</code> does the same thing except that the <strong>answers file will be overwritten</strong>.</p>
 <p>The <code>mkiocccentry -i answers ...</code> will still be required to confirm “<em>Yes/No</em>” questions.</p>
 <p>Use <code>mkiocccentry -Y -i answers ..</code> to force a yes answers with <strong>great caution</strong>
 because it might force a yes answer to something you do <strong>NOT</strong> want, such as a
-change in your code that violates a detected rule.</p>
+change in your code that violates a detected rule.
+The <code>mkiocccentry -i answers ..</code> will still be required to confirm “<em>Yes/No</em>” questions.
+While <code>mkiocccentry -Y -i answers ..</code> will force yes answers, use with <strong>great caution</strong>,
+because it might force a yes answer to something you do <strong>NOT</strong> want.</p>
 <p>To help with not having to repeatedly enter a UUID, put your UUID into a file and use
 <code>mkiocccentry -u uuidfile ...</code>, or use <code>mkiocccentry -U UUID ...</code> to give the <code>UUID</code>
 on the command line.</p>
 <p>If you wish to <strong>test</strong> that your submission passes the <code>mkiocccentry(1)</code> tests
-without having to type in in answers each time, you can use the <code>-d</code> or <code>-s seed</code>
+without having to type in answers each time, you can use the <code>-d</code> or <code>-s seed</code>
 option to <code>mkiocccentry</code> for the tool to pseudo-randomly create answers for you.
 For example:</p>
-<pre><code>    mkiocccentry -d workdir topdir</code></pre>
+<pre><code>mkiocccentry -d workdir topdir</code></pre>
 <p>Do <strong>NOT</strong> submit a tarball formed by <code>mkiocccentry -d ..</code> <strong>OR</strong> by
 <code>mkiocccentry -s seed ..</code> <strong>OR</strong> by using the <code>test</code> UUID!</p>
 <p>The <code>mkiocccentry(1)</code> tool creates an <code>xz(1)</code> compressed <strong>v7 format</strong> tarball using a <code>tar(1)</code>
 command of the form:</p>
-<pre><code>    cd workdir/UUID-slot_num &amp;&amp; tar --format=v7 -cJf submit.UUID-slot_num.timestamp.txz UUID-slot_num</code></pre>
+<pre><code>cd workdir/UUID-slot_num &amp;&amp; tar --format=v7 -cJf submit.UUID-slot_num.timestamp.txz UUID-slot_num</code></pre>
 <p>In many places the <code>mkiocccentry(1)</code> tool will prompt you to verify what you input, allowing you to
 correct details as you go along.</p>
 <p>Pressing the “<em>enter key</em>” at the <code>mkiocccentry(1)</code> tool prompts will allow you
@@ -785,7 +764,7 @@ run <code>txzchk(1)</code>, which will also run <code>fnamchk(1)</code>, as part
 <p>The use of <code>mkiocccentry -W ....</code> is <strong>highly discouraged</strong> as this may ignore
 warnings about a problem that may cause your submission to be <strong>REJECTED!</strong>”</p>
 <p>If <code>mkiocccentry</code> encounters an <strong>error</strong>, the program will exit and the xz
-compressed tarball <strong>will NOT be formed</strong>: this is a <strong>feature, not a bug</strong>!</p>
+compressed tarball <strong>will NOT be generated</strong>: this is a <strong>feature, not a bug</strong>!</p>
 <p>If you encounter a <strong>bug</strong> with the
 <a href="https://github.com/ioccc-src/mkiocccentry">mkiocccentry toolkit</a>
 <strong>PLEASE run the <code>bug_report.sh</code> script to help us out here!</strong></p>
@@ -795,9 +774,8 @@ then in order to run a tool outside the repo directory
 you will have to specify <code>mkiocccentry(1)</code> command line options to locate required tools
 such as <code>chkentry(1)</code> (<code>mkiocccentry -C chkentry ..</code>), <code>txzchk(1)</code> (<code>mkiocccentry -T txzchk ..</code>),
 and <code>fnamchk(1)</code> (<code>mkiocccentry -F fnamchk ..</code>).</p>
-<p>The <code>mkiocccentry(1)</code> tool will ignore any filename that begins with a “.” (dot).</p>
-<p>The <code>mkiocccentry(1)</code> tool will ignore any directory tree with a directory name that begins with a “.” (dot).</p>
-<p>The <code>mkiocccentry(1)</code> tool will all files that begin with <code>COPYING</code>, <code>COPYRIGHT</code>, and <code>LICENSE</code>, regardless
+<p>The <code>mkiocccentry(1)</code> tool will ignore any filename or directory that begins with a period (<code>.</code>).</p>
+<p>The <code>mkiocccentry(1)</code> tool will ignore all files that begin with <code>COPYING</code>, <code>COPYRIGHT</code>, and <code>LICENSE</code>, regardless
 of filename case.</p>
 <p>The <code>mkiocccentry(1)</code> tool will reject any of the following files if they are found directly under
 the top level directory (<code>topdir</code>):</p>
@@ -848,9 +826,275 @@ FAQ on “<a href="../faq.html#about_mkiocccentry">What is mkiocccentry in simpl
 <p>See
 FAQ on “<a href="../faq.html#mkiocccentry">What is the mkiocccentry tool, how do I obtain it and how do I use it</a>”.</p>
 <p>Jump to: <a href="#">top</a></p>
+<div id="make">
+<div id="makefile">
+<h1 id="makefiles">Makefiles</h1>
+</div>
+</div>
+<p class="leftbar">
+We <strong>recommend</strong> AND <strong>encourage</strong> you to use the example Makefile,
+as the starting point for your submission’s required <code>Makefile</code>:
+</p>
+<ul>
+<li><a href="https://github.com/ioccc-src/winner/blob/master/next/Makefile.example">view example Makefile</a></li>
+<li><a href="Makefile.example" download="Makefile">download example Makefile</a></li>
+</ul>
+<p class="leftbar">
+Feel free to modify the <code>Makefile</code> to suit your obfuscation
+needs.
+</p>
+<p class="leftbar">
+<strong>Please</strong> add a space between the <code>=</code> and the value of variables, in the
+<code>Makefile</code>, making sure that the <code>=</code> comes immediately after the name. See the
+example <code>Makefile</code> for examples.
+</p>
+<p class="leftbar">
+The rest of this section and its subsections will assume that you are using some
+variant of the example <code>Makefile</code>, again renamed as <code>Makefile</code>.
+</p>
+<p class="leftbar">
+We suggest that you compile your submission with a commonly available
+<code>-std=gnu17</code> (ISO C 2017 with GNU extensions) C compiler, via <code>clang(1)</code>
+and/or <code>gcc(1)</code>.
+</p>
+<div id="cflags">
+<div id="flags">
+<h2 id="default-compiler-flags">Default compiler flags</h2>
+</div>
+</div>
+<p class="leftbar">
+Unless you <strong>clearly state</strong> otherwise in your <code>remarks.md</code> file, <strong>AND</strong> put in
+your submission’s <code>Makefile</code>, we <strong>will</strong> compile using <code>-std=gnu17 -O3</code>!
+</p>
+<p class="leftbar">
+It <strong>is OK</strong> if you need to require your submission to <strong>NOT be</strong> compiled
+using the default <code>-std=gnu17 -O3</code> settings. Simply <strong>explain why</strong>
+your submission should NOT be compiled using <code>-std=gnu17 -O3</code> in
+your <code>remarks.md</code> file, <strong>AND</strong> adjust your <code>Makefile</code> accordingly.
+</p>
+<p class="leftbar">
+One reason that you might have to change the flags, is that the optimiser is
+known to break some programs, but there are certainly other possible valid
+reasons. Again, just update the <code>Makefile</code> and explain it in your <code>remarks.md</code>.
+See the <a href="#optimiser">optimiser section</a> for details for changing optimiser
+flags.
+</p>
+<p class="leftbar">
+For more fun when it comes to optimisers breaking code, see
+<a href="../1986/marshall/compilers.html">1986/marshall/compilers.html</a>.
+</p>
+<div id="compilers">
+<h2 id="default-compiler">Default compiler</h2>
+</div>
+<p class="leftbar">
+<strong>IMPORTANT NOTE</strong>: The use of <code>-std=gnu17</code> does <strong>NOT</strong> imply the use of the <code>gcc</code>
+compiler! We often start by compiling using the <strong>clang</strong> C compiler instead.
+</p>
+<p class="leftbar">
+<strong>PLEASE NOTE</strong>: in macOS, the compiler <code>gcc</code> found at <code>/usr/bin/gcc</code> is
+in truth the <code>clang</code> compiler, as <code>/usr/bin/gcc --version</code> will show!
+</p>
+<div id="cstd">
+<div id="standard">
+<h2 id="c-standard">C standard</h2>
+</div>
+</div>
+<p class="leftbar">
+You may change the standard under which your submission is compiled
+by modifying the <code>CSTD</code> Makefile variable. For example, to use <code>c99</code> instead:
+</p>
+<pre><code>    CSTD= -std=c99</code></pre>
+<div id="opt">
+<div id="optimization">
+<div id="optimisation">
+<div id="optimizer">
+<div id="optimiser">
+<h2 id="default-optimisation-level">Default optimisation level</h2>
+</div>
+</div>
+</div>
+</div>
+</div>
+<p class="leftbar">
+You may change the level of optimization and compiler debug level
+that your submission is compiled with, by modifying the <code>OPT</code> Makefile variable.
+For example, to compile without optimization, and to include debug symbols:
+</p>
+<pre><code>    OPT= -O0 -g3</code></pre>
+<div id="warnings">
+<div id="cwarn">
+<h2 id="compiler-warnings">Compiler warnings</h2>
+</div>
+</div>
+<p class="leftbar">
+The default warning flags are set via the <code>CWARN</code> variable, as shown in the
+example <code>Makefile</code>:
+</p>
+<pre><code>    # Common C compiler warning flags
+    #
+    CWARN= -Wall -Wextra ${CSILENCE} ${CUNKNOWN}</code></pre>
+<p class="leftbar">
+For details on <code>CSILENCE</code> and <code>CUNKNOWN</code>, see the <a href="#disabling-warnings">section on disabling
+warnings</a>.
+</p>
+<div id="weverything">
+<h3 id="the--weverything-option">The <code>-Weverything</code> option</h3>
+</div>
+<p class="leftbar">
+For compilers, such as <code>clang</code>, that have the <code>-Weverything</code> option,
+while you may wish to try it, you should read our
+FAQ on “<a href="../faq.html#weverything">clang -Weverything</a>”.
+We do <strong>NOT</strong> recommend that you put
+the use of <code>-Weverything</code> into your submission’s <code>Makefile</code> for the reasons
+cited there. This goes even if your version does not trigger a warning as some
+other version might!
+</p>
+<p class="leftbar">
+On the other hand, if <code>${CC}</code> has “<code>clang</code>” in the name, the example <code>Makefile</code> will
+automatically enable <code>-Weverything</code>, so you might have to use <code>-Wno-foo</code>
+options anyway, as detailed below. See the
+FAQ on “<a href="../faq.html#weverything">-Weverything</a>”
+for more details.
+</p>
+<p class="leftbar">
+If “<code>clang</code>” is NOT in <code>${CC}</code>, the <code>CWARN</code> variable will not be further
+modified.
+</p>
+<p class="leftbar">
+There is no real penalty for compiler warnings. Sometimes
+compiler warnings cannot be helped: especially in the case of
+obfuscated C. :-) So if you cannot easily get rid of a compiler
+warning, try not to fret too much.
+</p>
+<p class="leftbar">
+We <strong>LIKE</strong> code that has a minimum of warnings, especially under the
+more strict <code>-Wall -Wextra -pedantic</code> mode:
+</p>
+<pre><code>    CWARN= -Wall -Wextra -pedantic</code></pre>
+<p class="leftbar">
+The two previous guidelines might be thought by some as being somewhat
+contradictory. Isn’t life, and isn’t trying to satisfy “contradictory customer
+requirements” all too often like that? :-) Try to minimize warnings if you
+can.
+</p>
+<p class="leftbar">
+If you manage to produce very few warnings, or perhaps no warnings at
+all under the <code>-Wall -Wextra -pedantic</code> mode, then by all means brag about it in
+your <code>remarks.md</code> file <strong>AND BE SURE TO TELL US</strong> the OS, OS version, compiler
+and compiler version in which you observed this occurring (in case our OS and
+compiler produces a different result: so your submission won’t be penalized for
+not meeting your claims).
+</p>
+<p class="leftbar">
+On the other hand, some warnings cannot be disabled and are enabled by compilers
+without any warning option specified. These are sometimes inevitable in
+obfuscated code and even in some non-obfuscated code, and you should not worry
+about this, though it might be worth pointing out.
+</p>
+<p class="leftbar">
+For instance, some compilers like to warn about use of pointers as arrays, which seems to
+be dubious, as it obviously can’t (always) be avoided, being a big part of C, so
+you should not worry about this either; this is the warning
+<code>-Wunsafe-buffer-usage</code> and the way to disable it is <code>-Wno-unsafe-buffer-usage</code>.
+See also the
+FAQ on “<a href="../faq.html#forced_warnings">forced warnings</a>”
+and the
+FAQ on “<a href="../faq.html#weverything">-Weverything</a>”.
+</p>
+<h2 id="disabling-warnings">Disabling warnings</h2>
+<p class="leftbar">
+If you do have to disable warnings due to <code>-Weverything</code> automatically being
+included, you might wish to state this fact in your <code>remarks.md</code> file.
+And even without <code>-Weverything</code> there can be warnings, as noted above.
+</p>
+<p class="leftbar">
+If your submission issues lots of warnings but is otherwise
+marvelously obfuscated in multiple levels, don’t worry about it. Nevertheless,
+be sure that the warnings do not constitute a potential “<strong>show stopper</strong>”
+compiler problem. Be sure that compilers such as both <code>gcc</code> and <code>clang</code> won’t
+produce a compiler <strong>error</strong> and refuse to compile your code: unless for some
+reason that is what you intend to happen in which case document that too in your
+<code>remarks.md</code> file. :-)
+</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 class="leftbar">
+To turn off a compiler warning, in your submission’s <code>Makefile</code>,
+try something such as:
+</p>
+<pre><code>    CSILENCE= -Wno-some-thing -Wno-another-thing</code></pre>
+<p class="leftbar">
+For instance:
+</p>
+<pre><code>    CSILENCE= -Wno-parentheses -Wno-binding-in-condition -Wno-misleading-indentation</code></pre>
+<p class="leftbar">
+If you do add “<code>-Wno-foo</code>” to your Makefile, consider changing:
+</p>
+<pre><code>    CUNKNOWN=</code></pre>
+<p class="leftbar">
+to:
+</p>
+<pre><code>    CUNKNOWN= -Wno-unknown-warning-option</code></pre>
+<p class="leftbar">
+Some compilers have reported this as an error, however, and if you have
+such a compiler you might want to not add it, or at least note in your
+<code>remarks.md</code> file, which OS, OS version, compiler and compiler version
+that has such a problem.
+</p>
+<div id="macros">
+<h2 id="defining-macros-in-the-makefile">Defining macros in the Makefile</h2>
+</div>
+<p class="leftbar">
+If you need to define something on the compile line, use
+the <code>CDEFINE</code> Makefile variable. For example:
+</p>
+<pre><code>    CDEFINE= -Dfoo -Dbar=baz</code></pre>
+<p class="leftbar">
+<strong>NOTE</strong>: just because we offer a default way to use the <code>-D</code> option, we still
+do not like excess use of <code>-D</code> to get past size limits, especially since you
+could use <code>#define</code> in your code instead.
+</p>
+<div id="include">
+<h2 id="include-files-in-the-makefile">Include files in the Makefile</h2>
+</div>
+<p class="leftbar">
+If you need to include a file (as in <code>#include</code>) on the command line, use the
+<code>CINCLUDE</code> Makefile variable. For example:
+</p>
+<pre><code>    CINCLUDE= -include stdio.h</code></pre>
+<div id="magic">
+<h2 id="magic-in-the-makefile">Magic in the Makefile</h2>
+</div>
+<p class="leftbar">
+If you need to add other “<strong>magic</strong>” flags to your compile line,
+use the <code>COTHER</code> Makefile variable. For example:
+</p>
+<pre><code>    COTHER= -fno-math-errno</code></pre>
+<p class="leftbar">
+<strong>NOTE</strong>: <strong>We only recommend using “<em>magic</em>” flags if <em>BOTH</em> <code>gcc</code>
+<em>and</em> <code>clang</code></strong> support it.
+</p>
+<p class="leftbar">
+Again, please note that in macOS, <code>/usr/bin/gcc</code> is actually <code>clang</code>!
+</p>
+<div id="clobber">
+<h2 id="the-clobber-rule">The clobber rule</h2>
+</div>
+<p class="leftbar">
+When <code>make clobber</code> is invoked, we request that submissions be restored
+to their original submission state. For example, any temporary files
+(<strong>including</strong> the compiled program(s)) created during the build process, or
+during execution should be removed by the <code>clobber</code> rule. In other words, the
+only things that should be in the directory after running <code>make clobber</code> is what
+is in your submission tarball itself.
+</p>
 <div id="general">
 <h1 id="general-guidelines">General Guidelines</h1>
 </div>
+<div id="general">
+
+</div>
+<h1 id="general-overall-guidelines">General Overall Guidelines</h1>
 <p>These <a href="guidelines.html">guideline</a> are <strong>hints</strong> and <strong>suggestions</strong>, <strong>NOT</strong> <a href="rules.html">IOCCC rules</a>.</p>
 <p>While submissions that violate <a href="guidelines.html">guideline</a> are allowed,
 submissions that remain within the <a href="guidelines.html">IOCCC guidelines</a> are preferred.</p>
@@ -922,10 +1166,12 @@ misleading comments and variable names might be a <strong>VERY GOOD START</stron
 to a great submission!</p>
 <p>Jump to: <a href="#">top</a></p>
 <div id="likes">
+
+</div>
 <div id="dislikes">
+
+</div>
 <h1 id="our-likes-and-dislikes">OUR LIKES AND DISLIKES:</h1>
-</div>
-</div>
 <p>We <strong>VERY MUCH LIKE</strong> submissions that use an edited variant of the
 example Makefile, as described and linked to in the <a href="#makefile">Makefile section</a>,
 renamed as <code>Makefile</code> of course. This makes it easier for the <a href="../judges.html">IOCCC judges</a>
@@ -1196,8 +1442,8 @@ 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
 their submissions. In some cases tools have a “Save As” option that will
 prevent such trailing control-M’s being added.</p>
-<p>One should restrict libcurses to portable features found on BSD
-or Linux curses.</p>
+<p>One should restrict libcurses to portable features found on both BSD
+and Linux curses.</p>
 <p class="leftbar">
 If you do <code>#include &lt;curses.h&gt;</code> make <strong>CERTAIN</strong> you link in curses (i.e.
 <code>-lcurses</code>) and not ncurses (i.e. <code>-lncurses</code>).
@@ -1304,8 +1550,9 @@ is a <strong>hint</strong>. :-)</p>
 <p>Try to be even more creative!</p>
 <p>Jump to: <a href="#">top</a></p>
 <div id="fun">
-<h1 id="fundamental-guidelines">Fun😄damental Guidelines</h1>
+
 </div>
+<h1 id="fundamental-guidelines">Fun😄damental Guidelines</h1>
 <p>The reason for the times of day are so that key IOCCC events are <strong>calculated</strong>
 to be a <strong>fun</strong>ctional UTC time. :-)</p>
 <p>At least 2 of several reasons for selecting the prime, 2503, for
@@ -1412,10 +1659,12 @@ CPU, we might just try your submission on that emulator as well :-)</p>
 it? :-)</p>
 <p>Jump to: <a href="#">top</a></p>
 <div id="more-information">
+
+</div>
 <div id="information">
+
+</div>
 <h1 id="for-more-information">FOR MORE INFORMATION:</h1>
-</div>
-</div>
 <p>For questions or comments about the contest, see <a href="../contact.html">Contacting the IOCCC</a>.</p>
 <p><strong>Be SURE</strong> to review the <a href="index.html">IOCCC Rules and Guidelines</a> as they
 may (and <strong>often do</strong>) change from year to year.</p>