Merge pull request #2652 from xexyl/guidelines
Add note to guidelines about forced warnings
This commit is contained in:
9 files changed
+455
-193
No files matched your search
@@ -41,6 +41,7 @@ manifest.numbers
|
||||
.su[a-z]
|
||||
.*.sv[a-z]
|
||||
.*.sw[a-z]
|
||||
.sw[a-zA-Z0-9]
|
||||
.tmp.*
|
||||
year_prize.csv
|
||||
year_prize.numbers
|
||||
@@ -4,7 +4,7 @@
|
||||
make
|
||||
```
|
||||
|
||||
There is an alternate version based on the author's remarks. See [alternate
|
||||
There is an alternate version based on the author's remarks. See [Alternate
|
||||
code](#alternate-code).
|
||||
|
||||
|
||||
@@ -28,8 +28,8 @@ where `seed` is a number.
|
||||
|
||||
## Alternate code:
|
||||
|
||||
This code is formatted differently and is not the approach used by the author
|
||||
which is slower, inelegant and not as obscure, as the author put it.
|
||||
This code is formatted differently and is not the approach used by the author;
|
||||
it is slower, inelegant and not as obscure, as the author put it.
|
||||
|
||||
|
||||
### Alternate build:
|
||||
@@ -60,8 +60,8 @@ more while it puzzles out some puzzles: all in a puzzling way!
|
||||
to the `switch` statement. And if you think you can puzzle
|
||||
it out better, try solving [insane1.sudoku](%%REPO_URL%%/2005/aidan/insane1.sudoku) all by yourself!
|
||||
|
||||
NOTE: the tarball named by the author was removed after the files were extracted
|
||||
into the directory instead. These files were added to the list.
|
||||
**NOTE**: the tarball named by the author was removed after the files were
|
||||
extracted into the directory instead. These files were added to the list.
|
||||
|
||||
|
||||
## Author's remarks:
|
||||
|
||||
@@ -409,7 +409,7 @@ Location: <a href="../../location.html#GB">GB</a> - <em>United Kingdom of Great
|
||||
<!-- BEFORE: 1st line of markdown file: 2005/aidan/README.md -->
|
||||
<h2 id="to-build">To build:</h2>
|
||||
<pre><code> make</code></pre>
|
||||
<p>There is an alternate version based on the author’s remarks. See <a href="#alternate-code">alternate
|
||||
<p>There is an alternate version based on the author’s remarks. See <a href="#alternate-code">Alternate
|
||||
code</a>.</p>
|
||||
<h2 id="to-use">To use:</h2>
|
||||
<pre><code> ./aidan < puzzle
|
||||
@@ -419,8 +419,8 @@ code</a>.</p>
|
||||
<h2 id="try">Try:</h2>
|
||||
<pre><code> ./try.sh</code></pre>
|
||||
<h2 id="alternate-code">Alternate code:</h2>
|
||||
<p>This code is formatted differently and is not the approach used by the author
|
||||
which is slower, inelegant and not as obscure, as the author put it.</p>
|
||||
<p>This code is formatted differently and is not the approach used by the author;
|
||||
it is slower, inelegant and not as obscure, as the author put it.</p>
|
||||
<h3 id="alternate-build">Alternate build:</h3>
|
||||
<pre><code> make alt</code></pre>
|
||||
<h3 id="alternate-use">Alternate use:</h3>
|
||||
@@ -433,8 +433,8 @@ more while it puzzles out some puzzles: all in a puzzling way!</p>
|
||||
<p><code>goto</code> the source and notice the lack of functions. Jump
|
||||
to the <code>switch</code> statement. And if you think you can puzzle
|
||||
it out better, try solving <a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/2005/aidan/insane1.sudoku">insane1.sudoku</a> all by yourself!</p>
|
||||
<p>NOTE: the tarball named by the author was removed after the files were extracted
|
||||
into the directory instead. These files were added to the list.</p>
|
||||
<p><strong>NOTE</strong>: the tarball named by the author was removed after the files were
|
||||
extracted into the directory instead. These files were added to the list.</p>
|
||||
<h2 id="authors-remarks">Author’s remarks:</h2>
|
||||
<p>This program can solve a type of logic puzzle known as a
|
||||
<a href="https://en.wikipedia.org/wiki/Sudoku">Sudoku</a>, and also
|
||||
|
||||
+118
-78
@@ -4,8 +4,8 @@
|
||||
make
|
||||
```
|
||||
|
||||
NOTE: there is an alternate version for vi(m) like movements. See [alternate
|
||||
version](#alternate-code) below. If your terminal has problems with the
|
||||
**NOTE**: there is an alternate version for vi(m) like movements. See [Alternate
|
||||
code](#alternate-code) below. If your terminal has problems with the
|
||||
`stty(1)` commands try:
|
||||
|
||||
``` <!---sh-->
|
||||
@@ -62,7 +62,7 @@ something strange. This might also happen if you specify excessively large board
|
||||
dimensions. Try `100 100 100` for instance and see what happens!
|
||||
|
||||
|
||||
## Alternate version:
|
||||
## Alternate code:
|
||||
|
||||
The alternate version uses `vi(m)` like movement keys.
|
||||
|
||||
@@ -84,14 +84,19 @@ To compile the version without `stty(1)`:
|
||||
|
||||
Use `anon.alt` as you would `anon` with the change in movements:
|
||||
|
||||
```
|
||||
k | Move empty spot up
|
||||
h | Move empty spot left
|
||||
j | Move empty spot down
|
||||
l | Move empty spot right
|
||||
J | Move empty spot forwards
|
||||
K | Move empty spot backwards
|
||||
```
|
||||
|
||||
* `k`
|
||||
- Move empty spot up
|
||||
* `h`
|
||||
- Move empty spot left
|
||||
* `j`
|
||||
- Move empty spot down
|
||||
* `l`
|
||||
- Move empty spot right
|
||||
* `J`
|
||||
- Move empty spot forwards
|
||||
* `K`
|
||||
- Move empty spot backwards
|
||||
|
||||
|
||||
## Judges' remarks:
|
||||
@@ -130,9 +135,9 @@ To play with a 3D board, do something like this:
|
||||
./anon 3 3 3
|
||||
```
|
||||
|
||||
**WARNING: do NOT run the program with more than 3 command-line arguments.
|
||||
**WARNING**: do NOT run the program with more than 3 command-line arguments.
|
||||
This will trigger a bug that will cause it to crash or do something strange.
|
||||
:-)**
|
||||
:-)
|
||||
|
||||
Also, resist the temptation to create very large puzzles. The program does not
|
||||
attempt to resize your terminal for you, and will produce confusing output. It
|
||||
@@ -143,34 +148,38 @@ The empty space on the board is represented by a space filled with `#`
|
||||
characters instead of digits. To slide the tiles around, use the following
|
||||
keys:
|
||||
|
||||
```
|
||||
i | Slide the tile above the current empty space downwards.
|
||||
j | Slide the tile to the left of the current empty space to the right.
|
||||
k | Slide the tile below the current empty space upwards.
|
||||
l | Slide the tile to the right of the current empty space to the left.
|
||||
o | Slide the tile behind the current empty space forwards.
|
||||
n | Slide the tile in front of the current empty space backwards.
|
||||
```
|
||||
* `i`
|
||||
- Slide the tile above the current empty space downwards.
|
||||
* `j`
|
||||
- Slide the tile to the left of the current empty space to the right.
|
||||
* `k`
|
||||
- Slide the tile below the current empty space upwards.
|
||||
* `l`
|
||||
- Slide the tile to the right of the current empty space to the left.
|
||||
* `o`
|
||||
- Slide the tile behind the current empty space forwards.
|
||||
* `n`
|
||||
- Slide the tile in front of the current empty space backwards.
|
||||
|
||||
To quit the game:
|
||||
|
||||
```
|
||||
q | Quit the game.
|
||||
```
|
||||
To quit the game, hit `q`.
|
||||
|
||||
Note that, for example, sliding the tile above the current empty spot
|
||||
downwards will fill up the empty spot, and create a new empty spot above where
|
||||
the current empty spot was. Hence, you could think of the movement keys in
|
||||
terms of how they effectively "move" the empty spot:
|
||||
|
||||
```
|
||||
i | Move empty spot up
|
||||
j | Move empty spot left
|
||||
k | Move empty spot down
|
||||
l | Move empty spot right
|
||||
n | Move empty spot forwards
|
||||
o | Move empty spot backwards
|
||||
```
|
||||
* `i`
|
||||
- Move empty spot up
|
||||
* `j`
|
||||
- Move empty spot left
|
||||
* `k`
|
||||
- Move empty spot down
|
||||
* `l`
|
||||
- Move empty spot right
|
||||
* `n`
|
||||
- Move empty spot forwards
|
||||
* `o`
|
||||
- Move empty spot backwards
|
||||
|
||||
**NOTE:** as a measure of alleviating counter-productivity due to addiction to
|
||||
this game, particularly for those hardcore gamers who insist on solving a
|
||||
@@ -315,13 +324,13 @@ To avoid having to handle issues of `int` sizes, memory alignment, what exactly
|
||||
is on the stack between successive locations of `argc`, etc., the program
|
||||
(ab)uses the fact that `argc` must necessarily be allocated on an aligned
|
||||
address, and therefore, the range of memory between two `argc`s is aligned, and
|
||||
therefore safe to use as an array of `long`s.[\*] The program also compares the
|
||||
therefore safe to use as an array of `long`s.[^1] The program also compares the
|
||||
pointers as `long*` pointers, so that it will not have to deal with mapping
|
||||
bytes to larger types. The initial memory allocation is done by recursively
|
||||
calling `main()` until there is enough space on the stack (the exact number of
|
||||
recursive calls is, of course, architecture-dependent).
|
||||
|
||||
[\*] `long` was chosen instead of `int`, in order to skirt around pointer-size
|
||||
[^1]: `long` was chosen instead of `int`, in order to skirt around pointer-size
|
||||
issues on architectures like ia64. It really can be made anything large enough
|
||||
to hold both `int`s and pointers. `:-)`
|
||||
|
||||
@@ -330,10 +339,10 @@ array (pun intended), the program begins its real code. It uses `argc` to keep
|
||||
track of what it's supposed to be doing (since `main()` is the only function),
|
||||
and `argv` to point to the base of this array (which is computed differently
|
||||
based on how the architecture allocates the stack). Since this fills up the
|
||||
only two variables in the program, everything else is stored in the `MASS` [\*\*]
|
||||
only two variables in the program, everything else is stored in the `MASS` [^2]
|
||||
array.
|
||||
|
||||
[\*\*] for "Memory Allocated by Stack Smashing" :-)
|
||||
[^2]: for "Memory Allocated by Stack Smashing" :-)
|
||||
|
||||
Note that from this point on, all bets are off as to what the contents of the
|
||||
runtime stack are below the current recursive call to `main()`. We are
|
||||
@@ -450,29 +459,46 @@ program, and what the various state numbers are meant to do:
|
||||
|
||||
#### MASS usage map
|
||||
|
||||
```
|
||||
0 | Function return value
|
||||
1 | Function argument 1
|
||||
2 | Function argument 2
|
||||
3 | Function argument 3
|
||||
4 | Scratch register 1
|
||||
5 | Scratch register 2
|
||||
6 | Scratch register 3
|
||||
7 | Scratch register 4
|
||||
8 | Value of original argv :-)
|
||||
9 | Value of original argc :-)
|
||||
11 | Zero register (always set to 0)
|
||||
12 | Width of board
|
||||
13 | Length of board
|
||||
14 | Height of board
|
||||
15 | Current position of hole
|
||||
16 | Random seed for rand_r(3)
|
||||
18 | Scratch register used by state 18 :-)
|
||||
31 | field width for printing tiles
|
||||
32 | Start of board data
|
||||
```
|
||||
* `0`
|
||||
- Function return value
|
||||
* `1`
|
||||
- Function argument 1
|
||||
* `2`
|
||||
- Function argument 2
|
||||
* `3`
|
||||
- Function argument 3
|
||||
* `4`
|
||||
- Scratch register 1
|
||||
* `5`
|
||||
- Scratch register 2
|
||||
* `6`
|
||||
- Scratch register 3
|
||||
* `7`
|
||||
- Scratch register 4
|
||||
* `8`
|
||||
- Value of original argv :-)
|
||||
* `9`
|
||||
- Value of original argc :-)
|
||||
* `11`
|
||||
* Zero register (always set to 0)
|
||||
* `12`
|
||||
- Width of board
|
||||
* `13`
|
||||
- Length of board
|
||||
* `14`
|
||||
- Height of board
|
||||
* `15`
|
||||
- Current position of hole
|
||||
* `16`
|
||||
- Random seed for rand_r(3)
|
||||
* `18`
|
||||
- Scratch register used by state 18 :-)
|
||||
* `31`
|
||||
- Field width for printing tiles
|
||||
* `32`
|
||||
- Start of board data
|
||||
|
||||
(**CAVEAT:** not all of these mappings ended up in the final version of the
|
||||
(**CAVEAT**: not all of these mappings ended up in the final version of the
|
||||
program, mainly due to size limitations which entailed the trimming off of a
|
||||
lot of neat features in the game. It is left as an exercise for the reader to
|
||||
figure out which of these are actually used.)
|
||||
@@ -484,24 +510,38 @@ to be on all tested architectures.)
|
||||
|
||||
#### State number assignments
|
||||
|
||||
```
|
||||
1 | showhelp
|
||||
2 | showhelp
|
||||
3 | is 2D: start init
|
||||
4 | is 3D: start init
|
||||
5 | find allocation type
|
||||
6 | MASS init, bottom-up
|
||||
7 | MASS init, top-down
|
||||
8 | main program
|
||||
9 | generate() outer loop
|
||||
13 | render()
|
||||
14 | render() loop
|
||||
15 | exit(0)
|
||||
16 | pick a tile that hasn't occurred yet
|
||||
17 | inner loop of 16.
|
||||
18 | main loop
|
||||
19 | checkwin() loop
|
||||
```
|
||||
* `1`
|
||||
- `showhelp`
|
||||
* `2`
|
||||
- `showhelp`
|
||||
* `3`
|
||||
- is 2D: start init
|
||||
* `4`
|
||||
- is 3D: start init
|
||||
* `5`
|
||||
- find allocation type
|
||||
* `6`
|
||||
- MASS init, bottom-up
|
||||
* `7`
|
||||
- MASS init, top-down
|
||||
* `8`
|
||||
- main program
|
||||
* `9`
|
||||
- `generate()` outer loop
|
||||
* `13`
|
||||
- `render()`
|
||||
* `14`
|
||||
- `render()` loop
|
||||
* `15`
|
||||
- `exit(0)`
|
||||
* `16`
|
||||
- pick a tile that hasn't occurred yet
|
||||
* `17`
|
||||
- inner loop of `16`.
|
||||
* `18`
|
||||
- main loop
|
||||
* `19`
|
||||
- `checkwin()` loop
|
||||
|
||||
Note that some of the manually-implemented states (those not implemented by
|
||||
`do()`) respond to multiple state numbers. Also note that states 1-4
|
||||
|
||||
+241
-67
@@ -409,8 +409,8 @@ Location: <a href="../../location.html#ZZ">ZZ</a> - <em>Unknown location</em></l
|
||||
<!-- BEFORE: 1st line of markdown file: 2005/anon/README.md -->
|
||||
<h2 id="to-build">To build:</h2>
|
||||
<pre><code> make</code></pre>
|
||||
<p>NOTE: there is an alternate version for vi(m) like movements. See <a href="#alternate-code">alternate
|
||||
version</a> below. If your terminal has problems with the
|
||||
<p><strong>NOTE</strong>: there is an alternate version for vi(m) like movements. See <a href="#alternate-code">Alternate
|
||||
code</a> below. If your terminal has problems with the
|
||||
<code>stty(1)</code> commands try:</p>
|
||||
<pre><code> make anon-no_stty</code></pre>
|
||||
<p>This will compile <a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/2005/anon/anon.c">anon.c</a> as <code>anon</code> to not use
|
||||
@@ -438,7 +438,7 @@ hook you) and spending too much time playing. :-)</p>
|
||||
<p>If you specify more than three args the program might also crash or do
|
||||
something strange. This might also happen if you specify excessively large board
|
||||
dimensions. Try <code>100 100 100</code> for instance and see what happens!</p>
|
||||
<h2 id="alternate-version">Alternate version:</h2>
|
||||
<h2 id="alternate-code">Alternate code:</h2>
|
||||
<p>The alternate version uses <code>vi(m)</code> like movement keys.</p>
|
||||
<h3 id="alternate-build">Alternate build:</h3>
|
||||
<pre><code> make alt</code></pre>
|
||||
@@ -446,12 +446,32 @@ dimensions. Try <code>100 100 100</code> for instance and see what happens!</p>
|
||||
<pre><code> make alt-no_stty</code></pre>
|
||||
<h3 id="alternate-use">Alternate use:</h3>
|
||||
<p>Use <code>anon.alt</code> as you would <code>anon</code> with the change in movements:</p>
|
||||
<pre><code> k | Move empty spot up
|
||||
h | Move empty spot left
|
||||
j | Move empty spot down
|
||||
l | Move empty spot right
|
||||
J | Move empty spot forwards
|
||||
K | Move empty spot backwards</code></pre>
|
||||
<ul>
|
||||
<li><code>k</code>
|
||||
<ul>
|
||||
<li>Move empty spot up</li>
|
||||
</ul></li>
|
||||
<li><code>h</code>
|
||||
<ul>
|
||||
<li>Move empty spot left</li>
|
||||
</ul></li>
|
||||
<li><code>j</code>
|
||||
<ul>
|
||||
<li>Move empty spot down</li>
|
||||
</ul></li>
|
||||
<li><code>l</code>
|
||||
<ul>
|
||||
<li>Move empty spot right</li>
|
||||
</ul></li>
|
||||
<li><code>J</code>
|
||||
<ul>
|
||||
<li>Move empty spot forwards</li>
|
||||
</ul></li>
|
||||
<li><code>K</code>
|
||||
<ul>
|
||||
<li>Move empty spot backwards</li>
|
||||
</ul></li>
|
||||
</ul>
|
||||
<h2 id="judges-remarks">Judges’ remarks:</h2>
|
||||
<p>Taking the 4x4 board with 15 tiles to a whole new level, this entry takes this
|
||||
puzzle to a whole new dimension! While you puzzle out this puzzle, we invite
|
||||
@@ -473,9 +493,9 @@ For example, to play the original version of the Fifteen Puzzle:</p>
|
||||
<pre><code> ./anon 4 4</code></pre>
|
||||
<p>To play with a 3D board, do something like this:</p>
|
||||
<pre><code> ./anon 3 3 3</code></pre>
|
||||
<p><strong>WARNING: do NOT run the program with more than 3 command-line arguments.
|
||||
<p><strong>WARNING</strong>: do NOT run the program with more than 3 command-line arguments.
|
||||
This will trigger a bug that will cause it to crash or do something strange.
|
||||
:-)</strong></p>
|
||||
:-)</p>
|
||||
<p>Also, resist the temptation to create very large puzzles. The program does not
|
||||
attempt to resize your terminal for you, and will produce confusing output. It
|
||||
may also crash on you if you insist on running it with excessively large board
|
||||
@@ -483,24 +503,63 @@ dimensions. :-) (10x10x10 is considered a safe upper limit.)</p>
|
||||
<p>The empty space on the board is represented by a space filled with <code>#</code>
|
||||
characters instead of digits. To slide the tiles around, use the following
|
||||
keys:</p>
|
||||
<pre><code> i | Slide the tile above the current empty space downwards.
|
||||
j | Slide the tile to the left of the current empty space to the right.
|
||||
k | Slide the tile below the current empty space upwards.
|
||||
l | Slide the tile to the right of the current empty space to the left.
|
||||
o | Slide the tile behind the current empty space forwards.
|
||||
n | Slide the tile in front of the current empty space backwards.</code></pre>
|
||||
<p>To quit the game:</p>
|
||||
<pre><code> q | Quit the game.</code></pre>
|
||||
<ul>
|
||||
<li><code>i</code>
|
||||
<ul>
|
||||
<li>Slide the tile above the current empty space downwards.</li>
|
||||
</ul></li>
|
||||
<li><code>j</code>
|
||||
<ul>
|
||||
<li>Slide the tile to the left of the current empty space to the right.</li>
|
||||
</ul></li>
|
||||
<li><code>k</code>
|
||||
<ul>
|
||||
<li>Slide the tile below the current empty space upwards.</li>
|
||||
</ul></li>
|
||||
<li><code>l</code>
|
||||
<ul>
|
||||
<li>Slide the tile to the right of the current empty space to the left.</li>
|
||||
</ul></li>
|
||||
<li><code>o</code>
|
||||
<ul>
|
||||
<li>Slide the tile behind the current empty space forwards.</li>
|
||||
</ul></li>
|
||||
<li><code>n</code>
|
||||
<ul>
|
||||
<li>Slide the tile in front of the current empty space backwards.</li>
|
||||
</ul></li>
|
||||
</ul>
|
||||
<p>To quit the game, hit <code>q</code>.</p>
|
||||
<p>Note that, for example, sliding the tile above the current empty spot
|
||||
downwards will fill up the empty spot, and create a new empty spot above where
|
||||
the current empty spot was. Hence, you could think of the movement keys in
|
||||
terms of how they effectively “move” the empty spot:</p>
|
||||
<pre><code> i | Move empty spot up
|
||||
j | Move empty spot left
|
||||
k | Move empty spot down
|
||||
l | Move empty spot right
|
||||
n | Move empty spot forwards
|
||||
o | Move empty spot backwards</code></pre>
|
||||
<ul>
|
||||
<li><code>i</code>
|
||||
<ul>
|
||||
<li>Move empty spot up</li>
|
||||
</ul></li>
|
||||
<li><code>j</code>
|
||||
<ul>
|
||||
<li>Move empty spot left</li>
|
||||
</ul></li>
|
||||
<li><code>k</code>
|
||||
<ul>
|
||||
<li>Move empty spot down</li>
|
||||
</ul></li>
|
||||
<li><code>l</code>
|
||||
<ul>
|
||||
<li>Move empty spot right</li>
|
||||
</ul></li>
|
||||
<li><code>n</code>
|
||||
<ul>
|
||||
<li>Move empty spot forwards</li>
|
||||
</ul></li>
|
||||
<li><code>o</code>
|
||||
<ul>
|
||||
<li>Move empty spot backwards</li>
|
||||
</ul></li>
|
||||
</ul>
|
||||
<p><strong>NOTE:</strong> as a measure of alleviating counter-productivity due to addiction to
|
||||
this game, particularly for those hardcore gamers who insist on solving a
|
||||
10x10x10 puzzle during work hours, and also to give an upper bound to user
|
||||
@@ -612,22 +671,18 @@ call is greater or less than in the parent call.)</p>
|
||||
is on the stack between successive locations of <code>argc</code>, etc., the program
|
||||
(ab)uses the fact that <code>argc</code> must necessarily be allocated on an aligned
|
||||
address, and therefore, the range of memory between two <code>argc</code>s is aligned, and
|
||||
therefore safe to use as an array of <code>long</code>s.[*] The program also compares the
|
||||
therefore safe to use as an array of <code>long</code>s.<a href="#fn1" class="footnote-ref" id="fnref1" role="doc-noteref"><sup>1</sup></a> The program also compares the
|
||||
pointers as <code>long*</code> pointers, so that it will not have to deal with mapping
|
||||
bytes to larger types. The initial memory allocation is done by recursively
|
||||
calling <code>main()</code> until there is enough space on the stack (the exact number of
|
||||
recursive calls is, of course, architecture-dependent).</p>
|
||||
<p>[*] <code>long</code> was chosen instead of <code>int</code>, in order to skirt around pointer-size
|
||||
issues on architectures like ia64. It really can be made anything large enough
|
||||
to hold both <code>int</code>s and pointers. <code>:-)</code></p>
|
||||
<p>After the stack is deemed to have grown deep enough to be a sufficiently <code>long</code>
|
||||
array (pun intended), the program begins its real code. It uses <code>argc</code> to keep
|
||||
track of what it’s supposed to be doing (since <code>main()</code> is the only function),
|
||||
and <code>argv</code> to point to the base of this array (which is computed differently
|
||||
based on how the architecture allocates the stack). Since this fills up the
|
||||
only two variables in the program, everything else is stored in the <code>MASS</code> [**]
|
||||
only two variables in the program, everything else is stored in the <code>MASS</code> <a href="#fn2" class="footnote-ref" id="fnref2" role="doc-noteref"><sup>2</sup></a>
|
||||
array.</p>
|
||||
<p>[**] for “Memory Allocated by Stack Smashing” :-)</p>
|
||||
<p>Note that from this point on, all bets are off as to what the contents of the
|
||||
runtime stack are below the current recursive call to <code>main()</code>. We are
|
||||
overwriting frame pointers, return addresses, etc., with data. Hence, the
|
||||
@@ -717,26 +772,85 @@ key press. What could be more fun than to define such a case in terms of a
|
||||
are the mappings of various locations of the <code>MASS</code> to their usage in the
|
||||
program, and what the various state numbers are meant to do:</p>
|
||||
<h4 id="mass-usage-map">MASS usage map</h4>
|
||||
<pre><code> 0 | Function return value
|
||||
1 | Function argument 1
|
||||
2 | Function argument 2
|
||||
3 | Function argument 3
|
||||
4 | Scratch register 1
|
||||
5 | Scratch register 2
|
||||
6 | Scratch register 3
|
||||
7 | Scratch register 4
|
||||
8 | Value of original argv :-)
|
||||
9 | Value of original argc :-)
|
||||
11 | Zero register (always set to 0)
|
||||
12 | Width of board
|
||||
13 | Length of board
|
||||
14 | Height of board
|
||||
15 | Current position of hole
|
||||
16 | Random seed for rand_r(3)
|
||||
18 | Scratch register used by state 18 :-)
|
||||
31 | field width for printing tiles
|
||||
32 | Start of board data</code></pre>
|
||||
<p>(<strong>CAVEAT:</strong> not all of these mappings ended up in the final version of the
|
||||
<ul>
|
||||
<li><code>0</code>
|
||||
<ul>
|
||||
<li>Function return value</li>
|
||||
</ul></li>
|
||||
<li><code>1</code>
|
||||
<ul>
|
||||
<li>Function argument 1</li>
|
||||
</ul></li>
|
||||
<li><code>2</code>
|
||||
<ul>
|
||||
<li>Function argument 2</li>
|
||||
</ul></li>
|
||||
<li><code>3</code>
|
||||
<ul>
|
||||
<li>Function argument 3</li>
|
||||
</ul></li>
|
||||
<li><code>4</code>
|
||||
<ul>
|
||||
<li>Scratch register 1</li>
|
||||
</ul></li>
|
||||
<li><code>5</code>
|
||||
<ul>
|
||||
<li>Scratch register 2</li>
|
||||
</ul></li>
|
||||
<li><code>6</code>
|
||||
<ul>
|
||||
<li>Scratch register 3</li>
|
||||
</ul></li>
|
||||
<li><code>7</code>
|
||||
<ul>
|
||||
<li>Scratch register 4</li>
|
||||
</ul></li>
|
||||
<li><code>8</code>
|
||||
<ul>
|
||||
<li>Value of original argv :-)</li>
|
||||
</ul></li>
|
||||
<li><code>9</code>
|
||||
<ul>
|
||||
<li>Value of original argc :-)</li>
|
||||
</ul></li>
|
||||
<li><code>11</code>
|
||||
<ul>
|
||||
<li>Zero register (always set to 0)</li>
|
||||
</ul></li>
|
||||
<li><code>12</code>
|
||||
<ul>
|
||||
<li>Width of board</li>
|
||||
</ul></li>
|
||||
<li><code>13</code>
|
||||
<ul>
|
||||
<li>Length of board</li>
|
||||
</ul></li>
|
||||
<li><code>14</code>
|
||||
<ul>
|
||||
<li>Height of board</li>
|
||||
</ul></li>
|
||||
<li><code>15</code>
|
||||
<ul>
|
||||
<li>Current position of hole</li>
|
||||
</ul></li>
|
||||
<li><code>16</code>
|
||||
<ul>
|
||||
<li>Random seed for rand_r(3)</li>
|
||||
</ul></li>
|
||||
<li><code>18</code>
|
||||
<ul>
|
||||
<li>Scratch register used by state 18 :-)</li>
|
||||
</ul></li>
|
||||
<li><code>31</code>
|
||||
<ul>
|
||||
<li>Field width for printing tiles</li>
|
||||
</ul></li>
|
||||
<li><code>32</code>
|
||||
<ul>
|
||||
<li>Start of board data</li>
|
||||
</ul></li>
|
||||
</ul>
|
||||
<p>(<strong>CAVEAT</strong>: not all of these mappings ended up in the final version of the
|
||||
program, mainly due to size limitations which entailed the trimming off of a
|
||||
lot of neat features in the game. It is left as an exercise for the reader to
|
||||
figure out which of these are actually used.)</p>
|
||||
@@ -745,22 +859,72 @@ the <code>MASS</code>, because otherwise they may overwrite their original value
|
||||
memory allocation code saves them. Index 8 is deemed “safe enough”. (It seems
|
||||
to be on all tested architectures.)</p>
|
||||
<h4 id="state-number-assignments">State number assignments</h4>
|
||||
<pre><code> 1 | showhelp
|
||||
2 | showhelp
|
||||
3 | is 2D: start init
|
||||
4 | is 3D: start init
|
||||
5 | find allocation type
|
||||
6 | MASS init, bottom-up
|
||||
7 | MASS init, top-down
|
||||
8 | main program
|
||||
9 | generate() outer loop
|
||||
13 | render()
|
||||
14 | render() loop
|
||||
15 | exit(0)
|
||||
16 | pick a tile that hasn't occurred yet
|
||||
17 | inner loop of 16.
|
||||
18 | main loop
|
||||
19 | checkwin() loop</code></pre>
|
||||
<ul>
|
||||
<li><code>1</code>
|
||||
<ul>
|
||||
<li><code>showhelp</code></li>
|
||||
</ul></li>
|
||||
<li><code>2</code>
|
||||
<ul>
|
||||
<li><code>showhelp</code></li>
|
||||
</ul></li>
|
||||
<li><code>3</code>
|
||||
<ul>
|
||||
<li>is 2D: start init</li>
|
||||
</ul></li>
|
||||
<li><code>4</code>
|
||||
<ul>
|
||||
<li>is 3D: start init</li>
|
||||
</ul></li>
|
||||
<li><code>5</code>
|
||||
<ul>
|
||||
<li>find allocation type</li>
|
||||
</ul></li>
|
||||
<li><code>6</code>
|
||||
<ul>
|
||||
<li>MASS init, bottom-up</li>
|
||||
</ul></li>
|
||||
<li><code>7</code>
|
||||
<ul>
|
||||
<li>MASS init, top-down</li>
|
||||
</ul></li>
|
||||
<li><code>8</code>
|
||||
<ul>
|
||||
<li>main program</li>
|
||||
</ul></li>
|
||||
<li><code>9</code>
|
||||
<ul>
|
||||
<li><code>generate()</code> outer loop</li>
|
||||
</ul></li>
|
||||
<li><code>13</code>
|
||||
<ul>
|
||||
<li><code>render()</code></li>
|
||||
</ul></li>
|
||||
<li><code>14</code>
|
||||
<ul>
|
||||
<li><code>render()</code> loop</li>
|
||||
</ul></li>
|
||||
<li><code>15</code>
|
||||
<ul>
|
||||
<li><code>exit(0)</code></li>
|
||||
</ul></li>
|
||||
<li><code>16</code>
|
||||
<ul>
|
||||
<li>pick a tile that hasn’t occurred yet</li>
|
||||
</ul></li>
|
||||
<li><code>17</code>
|
||||
<ul>
|
||||
<li>inner loop of <code>16</code>.</li>
|
||||
</ul></li>
|
||||
<li><code>18</code>
|
||||
<ul>
|
||||
<li>main loop</li>
|
||||
</ul></li>
|
||||
<li><code>19</code>
|
||||
<ul>
|
||||
<li><code>checkwin()</code> loop</li>
|
||||
</ul></li>
|
||||
</ul>
|
||||
<p>Note that some of the manually-implemented states (those not implemented by
|
||||
<code>do()</code>) respond to multiple state numbers. Also note that states 1-4
|
||||
conveniently correspond to what the program should do when 1-4 arguments are
|
||||
@@ -784,6 +948,16 @@ smiley. :-)</p>
|
||||
|
||||
-->
|
||||
<!-- AFTER: last line of markdown file: 2005/anon/README.md -->
|
||||
<hr style="width:10%;text-align:left;margin-left:0">
|
||||
<section id="footnotes" class="footnotes footnotes-end-of-document" role="doc-endnotes">
|
||||
<h5>Footnotes</h5>
|
||||
<ol>
|
||||
<li id="fn1"><p><code>long</code> was chosen instead of <code>int</code>, in order to skirt around pointer-size
|
||||
issues on architectures like ia64. It really can be made anything large enough
|
||||
to hold both <code>int</code>s and pointers. <code>:-)</code><a href="#fnref1" class="footnote-back" role="doc-backlink">↩︎</a></p></li>
|
||||
<li id="fn2"><p>for “Memory Allocated by Stack Smashing” :-)<a href="#fnref2" class="footnote-back" role="doc-backlink">↩︎</a></p></li>
|
||||
</ol>
|
||||
</section>
|
||||
|
||||
<!-- END: this line ends content for HTML phase 21 by: bin/pandoc-wrapper.sh via bin/md2html.sh -->
|
||||
<!-- START: this line starts content for HTML phase 22 by: bin/output-index-inventory.sh via bin/md2html.sh -->
|
||||
|
||||
@@ -389,7 +389,7 @@
|
||||
|
||||
<!-- BEFORE: 1st line of markdown file: faq.md -->
|
||||
<h1 id="faq-table-of-contents">FAQ Table of Contents</h1>
|
||||
<p>This is FAQ version <strong>28.0.3 2024-07-27</strong>.</p>
|
||||
<p>This is FAQ version <strong>28.0.4 2024-08-24</strong>.</p>
|
||||
<h2 id="section-0---submitting-to-a-new-ioccc">Section 0 - <a href="#faq0">Submitting to a new IOCCC</a></h2>
|
||||
<ul>
|
||||
<li><a class="normal" href="#faq0_0">0.0 - How may I enter the IOCCC?</a></li>
|
||||
@@ -451,6 +451,7 @@
|
||||
<li><a class="normal" href="#faq3_19">3.19 - What kind of make(1) compatibility does the IOCCC support and will it support other kinds?</a></li>
|
||||
<li><a class="normal" href="#faq3_20">3.20 - How do I download individual winning entries or all winning entries of a given year?</a></li>
|
||||
<li><a class="normal" href="#faq3_21">3.21 - What are <code>try.sh</code> and <code>try.alt.sh</code> scripts and why should I use them?</a></li>
|
||||
<li><a class="normal" href="#faq3_22">3.22 - Are there any compiler warnings that I should not worry about?</a></li>
|
||||
</ul>
|
||||
<h2 id="section-4---changes-made-to-ioccc-entries">Section 4 - <a href="#faq4">Changes made to IOCCC entries</a></h2>
|
||||
<ul>
|
||||
@@ -2829,14 +2830,6 @@ warnings, and sometimes warnings about things that do not matter, some of which
|
||||
are frankly frivolous and often downright dubious.</p>
|
||||
<p>To enable this feature:</p>
|
||||
<pre><code> make clobber all CC=clang</code></pre>
|
||||
<p>or:</p>
|
||||
<pre><code> make clobber all 'CWARN+= -Weverything'</code></pre>
|
||||
<p>though it should be noted that if one tries <code>-Weverything</code> with compilers that
|
||||
are not <code>clang</code> they <em>might</em> see something like:</p>
|
||||
<pre><code> echo 'int main(void) {}' > foo.c ; cc -Weverything foo.c -o foo
|
||||
cc: error: unrecognized command-line option '-Weverything'</code></pre>
|
||||
<p>which means that it can’t even be compiled. Thus the proper way to do it is the
|
||||
first way, <code>make clobber all CC=clang</code>.</p>
|
||||
<p>IOCCC authors who have access to <code>clang</code> might wish to try their
|
||||
hand at compiling with <code>-Weverything</code> while using a minimum of <code>-Wno-foo</code>
|
||||
statements. Sometimes there is a technical or pedantic issue that
|
||||
@@ -2863,7 +2856,7 @@ warnings, and we find a warning situation, this may diminish the value of your
|
||||
entry as it is not as documented. Thus it might be wise to point this out and
|
||||
if you can test it in multiple platforms (or versions of <code>clang</code>, see
|
||||
below note) this would be advisable.</p>
|
||||
<p>NOTE: different versions of <code>clang</code> have other differences as well. For instance
|
||||
<p><strong>NOTE</strong>: different versions of <code>clang</code> have other differences as well. For instance
|
||||
a defect of <code>clang</code> that required numerous entries to be fixed for clang is that it
|
||||
requires that <code>main()</code>’s arguments to be of a specific type. However some
|
||||
versions of <code>clang</code> are more strict in the number of args allowed. These reasons
|
||||
@@ -3178,9 +3171,9 @@ provided by the author and any other file in the winning entry, found under the
|
||||
entry’s subdirectory.</p>
|
||||
<p>If you downloaded <code>1984/mullender/1984_mullender.tar.bz2</code>, for instance, you might
|
||||
then do:</p>
|
||||
<div class="sourceCode" id="cb67"><pre class="sourceCode sh"><code class="sourceCode bash"><span id="cb67-1"><a href="#cb67-1" aria-hidden="true" tabindex="-1"></a> <span class="bu">cd</span> 1984/mullender</span>
|
||||
<span id="cb67-2"><a href="#cb67-2" aria-hidden="true" tabindex="-1"></a> <span class="fu">make</span> everything</span>
|
||||
<span id="cb67-3"><a href="#cb67-3" aria-hidden="true" tabindex="-1"></a> <span class="ex">./mullender.alt</span></span></code></pre></div>
|
||||
<div class="sourceCode" id="cb65"><pre class="sourceCode sh"><code class="sourceCode bash"><span id="cb65-1"><a href="#cb65-1" aria-hidden="true" tabindex="-1"></a> <span class="bu">cd</span> 1984/mullender</span>
|
||||
<span id="cb65-2"><a href="#cb65-2" aria-hidden="true" tabindex="-1"></a> <span class="fu">make</span> everything</span>
|
||||
<span id="cb65-3"><a href="#cb65-3" aria-hidden="true" tabindex="-1"></a> <span class="ex">./mullender.alt</span></span></code></pre></div>
|
||||
<p>to compile all versions and then run the alternate version (if you have
|
||||
a PDP-11 or VAX-11 you would be able to run the original version). For more help
|
||||
on compiling entries, see also the
|
||||
@@ -3221,8 +3214,8 @@ if you switched to each entry’s directory and ran <code>make everything</code>
|
||||
<p>If you download the 1984 tarball, i.e. <code>1984/1984.tar.bz2</code>, then you might
|
||||
extract it and then switch to the directory and compile everything of each
|
||||
entry:</p>
|
||||
<div class="sourceCode" id="cb68"><pre class="sourceCode sh"><code class="sourceCode bash"><span id="cb68-1"><a href="#cb68-1" aria-hidden="true" tabindex="-1"></a> <span class="bu">cd</span> 1984</span>
|
||||
<span id="cb68-2"><a href="#cb68-2" aria-hidden="true" tabindex="-1"></a> <span class="fu">make</span> everything</span></code></pre></div>
|
||||
<div class="sourceCode" id="cb66"><pre class="sourceCode sh"><code class="sourceCode bash"><span id="cb66-1"><a href="#cb66-1" aria-hidden="true" tabindex="-1"></a> <span class="bu">cd</span> 1984</span>
|
||||
<span id="cb66-2"><a href="#cb66-2" aria-hidden="true" tabindex="-1"></a> <span class="fu">make</span> everything</span></code></pre></div>
|
||||
<p>For more help on compiling entries, see also the
|
||||
FAQ on “<a href="#make_rules">IOCCC Makefile rules</a>”.</p>
|
||||
<p>Of course in this case you can also switch to individual entries and look at the
|
||||
@@ -3252,6 +3245,23 @@ and there are some other benefits as well which you would miss if you did not
|
||||
use them. Nevertheless, if you prefer to do it manually, whether to help you
|
||||
process or appreciate the entry more, then please do so.</p>
|
||||
<p>Jump to: <a href="#">top</a></p>
|
||||
<div id="faq3_22">
|
||||
<div id="forced_warnings">
|
||||
<h3 id="are-there-any-compiler-warnings-that-i-should-not-worry-about">3.22 - Are there any compiler warnings that I should not worry about?</h3>
|
||||
</div>
|
||||
</div>
|
||||
<p>There are unfortunately some warnings that cannot be disabled; they are always
|
||||
enabled whatever warning options you have enabled. Also, there is a warning that
|
||||
is enabled whenever you act on <code>char *</code>s, saying it is unsafe buffer usage, even
|
||||
when it’s not (this might be enabled by <code>-Weverything</code> but it might not be; for
|
||||
more details on why we use <code>-Weverything</code> in Clang see the FAQ on
|
||||
“<a href="#weverything"><code>-Weverything</code></a>”), and it is not detrimental to your submission
|
||||
if you disable this). This warning happens to be <code>-Wno-unsafe-buffer-usage</code>.</p>
|
||||
<p>So in short, no you should not worry about these as they are sometimes
|
||||
inevitable in obfuscated code and even non-obfuscated code.</p>
|
||||
<p>If you <em>can</em> work past this it might be good but this is not something that
|
||||
should be worried about too much as this is on the compiler developers, not you.</p>
|
||||
<p>Jump to: <a href="#">top</a></p>
|
||||
<div id="faq4">
|
||||
<h2 id="section-4-changes-made-to-ioccc-entries">Section 4: Changes made to IOCCC entries</h2>
|
||||
</div>
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# FAQ Table of Contents
|
||||
|
||||
This is FAQ version **28.0.3 2024-07-27**.
|
||||
This is FAQ version **28.0.4 2024-08-24**.
|
||||
|
||||
|
||||
## Section 0 - [Submitting to a new IOCCC](#faq0)
|
||||
@@ -63,6 +63,7 @@ This is FAQ version **28.0.3 2024-07-27**.
|
||||
- <a class="normal" href="#faq3_19">3.19 - What kind of make(1) compatibility does the IOCCC support and will it support other kinds?</a>
|
||||
- <a class="normal" href="#faq3_20">3.20 - How do I download individual winning entries or all winning entries of a given year?</a>
|
||||
- <a class="normal" href="#faq3_21">3.21 - What are `try.sh` and `try.alt.sh` scripts and why should I use them?</a>
|
||||
- <a class="normal" href="#faq3_22">3.22 - Are there any compiler warnings that I should not worry about?</a>
|
||||
|
||||
|
||||
## Section 4 - [Changes made to IOCCC entries](#faq4)
|
||||
@@ -3074,23 +3075,6 @@ To enable this feature:
|
||||
make clobber all CC=clang
|
||||
```
|
||||
|
||||
or:
|
||||
|
||||
``` <!---sh-->
|
||||
make clobber all 'CWARN+= -Weverything'
|
||||
```
|
||||
|
||||
though it should be noted that if one tries `-Weverything` with compilers that
|
||||
are not `clang` they _might_ see something like:
|
||||
|
||||
``` <!---sh-->
|
||||
echo 'int main(void) {}' > foo.c ; cc -Weverything foo.c -o foo
|
||||
cc: error: unrecognized command-line option '-Weverything'
|
||||
```
|
||||
|
||||
which means that it can't even be compiled. Thus the proper way to do it is the
|
||||
first way, `make clobber all CC=clang`.
|
||||
|
||||
IOCCC authors who have access to `clang` might wish to try their
|
||||
hand at compiling with `-Weverything` while using a minimum of `-Wno-foo`
|
||||
statements. Sometimes there is a technical or pedantic issue that
|
||||
@@ -3121,7 +3105,7 @@ entry as it is not as documented. Thus it might be wise to point this out and
|
||||
if you can test it in multiple platforms (or versions of `clang`, see
|
||||
below note) this would be advisable.
|
||||
|
||||
NOTE: different versions of `clang` have other differences as well. For instance
|
||||
**NOTE**: different versions of `clang` have other differences as well. For instance
|
||||
a defect of `clang` that required numerous entries to be fixed for clang is that it
|
||||
requires that `main()`'s arguments to be of a specific type. However some
|
||||
versions of `clang` are more strict in the number of args allowed. These reasons
|
||||
@@ -3766,6 +3750,29 @@ and there are some other benefits as well which you would miss if you did not
|
||||
use them. Nevertheless, if you prefer to do it manually, whether to help you
|
||||
process or appreciate the entry more, then please do so.
|
||||
|
||||
Jump to: [top](#)
|
||||
|
||||
<div id="faq3_22">
|
||||
<div id="forced_warnings">
|
||||
### 3.22 - Are there any compiler warnings that I should not worry about?
|
||||
</div>
|
||||
</div>
|
||||
|
||||
There are unfortunately some warnings that cannot be disabled; they are always
|
||||
enabled whatever warning options you have enabled. Also, there is a warning that
|
||||
is enabled whenever you act on `char *`s, saying it is unsafe buffer usage, even
|
||||
when it's not (this might be enabled by `-Weverything` but it might not be; for
|
||||
more details on why we use `-Weverything` in Clang see the FAQ on
|
||||
"[`-Weverything`](#weverything)"), and it is not detrimental to your submission
|
||||
if you disable this). This warning happens to be `-Wno-unsafe-buffer-usage`.
|
||||
|
||||
So in short, no you should not worry about these as they are sometimes
|
||||
inevitable in obfuscated code and even non-obfuscated code.
|
||||
|
||||
If you *can* work past this it might be good but this is not something that
|
||||
should be worried about too much as this is on the compiler developers, not you.
|
||||
|
||||
|
||||
Jump to: [top](#)
|
||||
|
||||
|
||||
|
||||
+16
-2
@@ -424,7 +424,7 @@ writing by <a href="../contact.html">contacting the judges</a>.</p>
|
||||
<h2 id="ioccc-guidelines-version">IOCCC Guidelines version</h2>
|
||||
</div>
|
||||
<p class="leftbar">
|
||||
These <a href="guidelines.html">IOCCC guidelines</a> are version <strong>28.13 2024-08-22</strong>.
|
||||
These <a href="guidelines.html">IOCCC guidelines</a> are version <strong>28.14 2024-08-24</strong>.
|
||||
</p>
|
||||
<p><strong>IMPORTANT</strong>: Be <strong>SURE</strong> to read the <a href="rules.html">IOCCC rules</a>.</p>
|
||||
<div id="change_marks">
|
||||
@@ -905,11 +905,25 @@ compiler produces a different result: so your submission won’t be penalized fo
|
||||
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.
|
||||
</p>
|
||||
<p class="leftbar">
|
||||
Additionally, some compilers like to warn about certain use of <code>char *</code>s which
|
||||
is not only likely dubious itself it obviously can’t (always) be avoided so you should
|
||||
not worry about this either; this is the warning <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"><code>-Weverything</code></a>”.
|
||||
</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 compile <strong>error</strong> and refuse to compile your code: unless for some
|
||||
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>
|
||||
|
||||
+18
-2
@@ -48,7 +48,7 @@ writing by [contacting the judges](../contact.html).
|
||||
</div>
|
||||
|
||||
<p class="leftbar">
|
||||
These [IOCCC guidelines](guidelines.html) are version **28.13 2024-08-22**.
|
||||
These [IOCCC guidelines](guidelines.html) are version **28.14 2024-08-24**.
|
||||
</p>
|
||||
|
||||
**IMPORTANT**: Be **SURE** to read the [IOCCC rules](rules.html).
|
||||
@@ -651,12 +651,28 @@ 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.
|
||||
</p>
|
||||
|
||||
<p class="leftbar">
|
||||
Additionally, some compilers like to warn about certain use of `char *`s which
|
||||
is not only likely dubious itself it obviously can't (always) be avoided so you should
|
||||
not worry about this either; this is the warning `-Wno-unsafe-buffer-usage`. See
|
||||
also the
|
||||
FAQ on "[forced warnings](../faq.html#forced_warnings)"
|
||||
and the
|
||||
FAQ on "[`-Weverything`](../faq.html#weverything)".
|
||||
</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 "**show stopper**"
|
||||
compiler problem. Be sure that compilers such as both `gcc` and `clang` won't
|
||||
produce a compile **error** and refuse to compile your code: unless for some
|
||||
produce a compiler **error** 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
|
||||
`remarks.md` file. :-)
|
||||
</p>
|
||||
|
||||
Reference in new issue
Block a user