Fixes in 1998 html files

This includes some notices to those who wish for a greater challenge.

In the 1998/schweikh3 the man page (and its copy to demonstrate the
entry) have been updated slightly but only in comment (move 'or' from
the command suggested to render it in text to its own line before the
next command also in comment).

The bugs file was updated for an entry or two.
This commit is contained in:
Cody Boone Ferguson committed 2024-07-29 08:47:22 -07:00
1 parent e297d4541a
commit 1fad29cd2f
28 files changed
+647 -370

No files matched your search

+5 -13
View File
@@ -116,25 +116,17 @@ is the same as
**If you want a greater challenge, don't read any further**:
just try to understand the program without running the command below.
If you get stuck, come back and read the below.
If you get stuck, come back and run the following command:
The file [dorssel.html](dorssel.html) contains all the information needed to
understand this program.
For more information you might also try:
``` <!---sh-->
./dorssel < dorssel.md
```
### NOTICE to those who wish for a greater challenge:
**If you want a greater challenge, don't read any further**:
just try to understand the program via the source.
If you get stuck, come back and read below for additional hints and information.
- The file [dorssel.html](dorssel.html) contains all the information needed to
understand this program. For spoiler information, try:
<!--
Copyright © 1984-2024 by Landon Curt Noll. All Rights Reserved.
+60 -38
View File
@@ -423,7 +423,7 @@ counter before shifting out each symbol, such as</p>
encoding &gt;&gt;= 1;
} while (length--);</code></pre>
<p>We can also use the remaining bits to <em>include</em> the counter</p>
<pre><code> length 1: 00000.1x E &gt; 00000.11
<pre><code> length 1: 00000.1x `E &gt; 00000.11
length 2: 0000.1xx
length 3: 000.1xxx
length 4: 00.1xxxx Z &gt; 00.11100
@@ -438,11 +438,11 @@ this is not very pleasant, as some Morse sequences will end up having
an ASCII value &lt; 32, i.e. they will be control codes. This would make
the initializing (encoding) string awkward. Hence I came up with the
following</p>
<pre><code> length 1: 0010010x E &gt; 00100101 (= &#39;%&#39;)
length 2: 001010xx
length 3: 00110xxx
length 4: 0100xxxx Z &gt; 01001100 (= &#39;L&#39;)
length 5: 011xxxxx 3 &gt; 01100111 (= &#39;g&#39;)</code></pre>
<pre><code>length 1: 0010010x E &gt; 00100101 (= &#39;%&#39;)
length 2: 001010xx
length 3: 00110xxx
length 4: 0100xxxx Z &gt; 01001100 (= &#39;L&#39;)
length 5: 011xxxxx 3 &gt; 01100111 (= &#39;g&#39;)</code></pre>
<p>Notice these encodings in the initialization string. Only the coding for
<code>5</code> needs an escape (<code>5 = ..... &gt; 01111111 = '\177'</code>). The way the length
is encoded still allows the encoding to be its own counter:</p>
@@ -454,13 +454,14 @@ is encoded still allows the encoding to be its own counter:</p>
Note that the calculation for the next value of <code>encoding</code> is done at <code>int</code>
precision, so that the actual value of the <code>char</code> remains <code>&lt;= 127</code>.</p>
<p>The character <code>'-'</code> (ASCII 45) and <code>'.'</code> (ASCII 46) are conveniently in
sequence, so the putchar can simply be</p>
sequence, so the <code>putchar(3)</code> can simply be</p>
<pre><code> putchar(45 + encoding % 2);</code></pre>
<p>I used the modulo operator this time, because <code>+</code> takes precedence over <code>&amp;</code>.
The assignment can be incorporated into the <code>while</code> control test, and a
<code>do-while</code> loop with a body of a single expression statement can be written
as a <code>while</code> loop with a comma operator in the test:</p>
<pre><code> while(putchar(45 + encoding % 2), encoding = encoding + 32 &gt;&gt; 1);</code></pre>
<pre><code> while(putchar(45 + encoding % 2),
encoding = encoding + 32 &gt;&gt; 1);</code></pre>
<p>Voila.</p>
<p>Now, the decoding of Morse codes is just the reverse. We shift in <code>0</code>s
and <code>1</code>s as we scan the line. But: we have to scan from back to front
@@ -484,23 +485,23 @@ and letters. This is OK, since neither of these characters, or the <code>'\0'</c
is a valid encoding ! We must, however, use <code>memchr(3)</code> instead of <code>strchr(3)</code> in
the decoding lookup because of this <code>'\0'</code>. Since it is far more obscure
this way, I hope you’ll forgive me.</p>
<p>The outline of the program is roughly as follows</p>
<p>The outline of the program is roughly as follows (pseudo C):</p>
<pre><code> while (more lines) {
if (line is in morse) {
while (more characters) {
skip next sequence
if (&#39; &#39;)
putchar(&#39; &#39;);
else
decode_sequence; /* backwards */
}
} else {
while (more characters) {
if (isalnum)
encode_character;
putchar(&#39; &#39;);
}
}</code></pre>
if (line is in morse) {
while (more characters) {
skip next sequence
if (&#39; &#39;)
putchar(&#39; &#39;);
else
decode_sequence; /* backwards */
}
} else {
while (more characters) {
if (isalnum)
encode_character;
putchar(&#39; &#39;);
}
}</code></pre>
<p>Because of the <em>two</em> <code>while(more characters)</code> loops are the same, I’ve
exchanged the <code>if(line is in morse)</code> and the two <code>while</code> loops (so there
is <em>single</em> <code>while</code> loop). However, we must now store the <code>if(line is in morse)</code> test for efficiency (it would be stupid to test the entire line
@@ -512,27 +513,48 @@ line of text. This does not disturb the <code>if (line is in morse)</code> test,
as the temporary <code>l[0]</code> will remain <code>!= 0</code>.</p>
<p>I’ve put the <code>if</code>s in the above layout into a single switch. Hope you don’t
mind ;-)</p>
<p>Summary of the use of l[999]:</p>
<pre><code> l[0] result of &quot;is this line in morse&quot; test
l[0] temporary shift during encoding
l[0] - l[33] Morse codings (letters and digits, plus garbage)
l[11] - l[14] strspn argument
l[12] - l[14] strspn argument
l[34] terminator for backward decoding
l[35] - l[998] input line</code></pre>
<p>Summary of the use of <code>l[999]</code>:</p>
<ul>
<li><code>l[0]</code>
<ul>
<li><strong>result of “is this line in morse” test</strong></li>
</ul></li>
<li><code>l[0]</code>
<ul>
<li><strong>temporary shift during encoding</strong></li>
</ul></li>
<li><code>l[0] - l[33]</code>
<ul>
<li><strong>Morse codings (letters and digits, plus garbage)</strong></li>
</ul></li>
<li><code>l[11] - l[14]</code>
<ul>
<li><strong><code>strspn(3)</code> argument</strong></li>
</ul></li>
<li><code>l[12] - l[14]</code>
<ul>
<li><strong><code>strspn(3)</code> argument</strong></li>
</ul></li>
<li><code>l[34]</code>
<ul>
<li><strong>terminator for backward decoding</strong></li>
</ul></li>
<li><code>l[35] - l[998]</code>
<ul>
<li><strong>input line</strong></li>
</ul></li>
</ul>
<hr style="width:10%;text-align:left;margin-left:0">
<p>Selected notes:</p>
<ul>
<li>We don’t need to declare <code>isalnum(3)</code> (or include ctype.h) as its implicit
declaration is correct (int argument, int result). This is not so for
<li>We don’t need to declare <code>isalnum(3)</code> (or include <code>ctype.h</code>) as its implicit
declaration is correct (<code>int</code> argument, <code>int</code> result). This is not so for
<code>strlen(3)</code>, <code>strspn(3)</code>, and <code>memchr(3)</code> as they use <code>size_t</code>.</li>
<li>During development, my gcc 2.7.2.3 had an internal compiler error (signal
<ol start="6" type="1">
<li>on code that was correct !</li>
</ol></li>
6) on code that was correct !</li>
<li>lclint 2.4b thinks that “the observer is modified” a couple of times,
whereas it is not. Well, it is, but there is a sequence point in between.</li>
<li>lclint 2.4b parses line 13 as <code>&lt;error&gt;</code>, whereas it is correct code.</li>
<li>lclint 2.4b parses <a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1998/dorssel/dorssel.c:L13">line 13</a> as <code>&lt;error&gt;</code>, whereas it is correct code.</li>
<li>lclint 2.4b is positive the second <code>while</code> loop is infinite, whereas it is
not.</li>
</ul>
+49 -37
View File
@@ -53,7 +53,7 @@ counter before shifting out each symbol, such as
We can also use the remaining bits to *include* the counter
```
length 1: 00000.1x E > 00000.11
length 1: 00000.1x `E > 00000.11
length 2: 0000.1xx
length 3: 000.1xxx
length 4: 00.1xxxx Z > 00.11100
@@ -76,11 +76,11 @@ the initializing (encoding) string awkward. Hence I came up with the
following
```
length 1: 0010010x E > 00100101 (= '%')
length 2: 001010xx
length 3: 00110xxx
length 4: 0100xxxx Z > 01001100 (= 'L')
length 5: 011xxxxx 3 > 01100111 (= 'g')
length 1: 0010010x E > 00100101 (= '%')
length 2: 001010xx
length 3: 00110xxx
length 4: 0100xxxx Z > 01001100 (= 'L')
length 5: 011xxxxx 3 > 01100111 (= 'g')
```
Notice these encodings in the initialization string. Only the coding for
@@ -99,7 +99,7 @@ Note that the calculation for the next value of `encoding` is done at `int`
precision, so that the actual value of the `char` remains `<= 127`.
The character `'-'` (ASCII 45) and `'.'` (ASCII 46) are conveniently in
sequence, so the putchar can simply be
sequence, so the `putchar(3)` can simply be
``` <!---c-->
putchar(45 + encoding % 2);
@@ -111,7 +111,8 @@ The assignment can be incorporated into the `while` control test, and a
as a `while` loop with a comma operator in the test:
``` <!---c-->
while(putchar(45 + encoding % 2), encoding = encoding + 32 >> 1);
while(putchar(45 + encoding % 2),
encoding = encoding + 32 >> 1);
```
Voila.
@@ -141,25 +142,25 @@ is a valid encoding ! We must, however, use `memchr(3)` instead of `strchr(3)`
the decoding lookup because of this `'\0'`. Since it is far more obscure
this way, I hope you'll forgive me.
The outline of the program is roughly as follows
The outline of the program is roughly as follows (pseudo C):
```
while (more lines) {
if (line is in morse) {
while (more characters) {
skip next sequence
if (' ')
putchar(' ');
else
decode_sequence; /* backwards */
}
} else {
while (more characters) {
if (isalnum)
encode_character;
putchar(' ');
}
if (line is in morse) {
while (more characters) {
skip next sequence
if (' ')
putchar(' ');
else
decode_sequence; /* backwards */
}
} else {
while (more characters) {
if (isalnum)
encode_character;
putchar(' ');
}
}
```
Because of the *two* `while(more characters)` loops are the same, I've
@@ -176,30 +177,41 @@ as the temporary `l[0]` will remain `!= 0`.
I've put the `if`s in the above layout into a single switch. Hope you don't
mind ;-)
Summary of the use of l[999]:
Summary of the use of `l[999]`:
```
l[0] result of "is this line in morse" test
l[0] temporary shift during encoding
l[0] - l[33] Morse codings (letters and digits, plus garbage)
l[11] - l[14] strspn argument
l[12] - l[14] strspn argument
l[34] terminator for backward decoding
l[35] - l[998] input line
```
- `l[0]`
* **result of "is this line in morse" test**
- `l[0]`
* **temporary shift during encoding**
- `l[0] - l[33]`
* **Morse codings (letters and digits, plus garbage)**
- `l[11] - l[14]`
* **`strspn(3)` argument**
- `l[12] - l[14]`
* **`strspn(3)` argument**
- `l[34]`
* **terminator for backward decoding**
- `l[35] - l[998]`
* **input line**
<hr style="width:10%;text-align:left;margin-left:0">
Selected notes:
- We don't need to declare `isalnum(3)` (or include ctype.h) as its implicit
declaration is correct (int argument, int result). This is not so for
- We don't need to declare `isalnum(3)` (or include `ctype.h`) as its implicit
declaration is correct (`int` argument, `int` result). This is not so for
`strlen(3)`, `strspn(3)`, and `memchr(3)` as they use `size_t`.
- During development, my gcc 2.7.2.3 had an internal compiler error (signal
6) on code that was correct !
6\) on code that was correct !
- lclint 2.4b thinks that "the observer is modified" a couple of times,
whereas it is not. Well, it is, but there is a sequence point in between.
- lclint 2.4b parses line 13 as `<error>`, whereas it is correct code.
- lclint 2.4b parses [line 13](%%REPO_URL%%/1998/dorssel/dorssel.c:L13) as `<error>`, whereas it is correct code.
- lclint 2.4b is positive the second `while` loop is infinite, whereas it is
not.
+5 -10
View File
@@ -474,17 +474,12 @@ text that can be reversibly Morsified, i.e.</li>
<pre><code> ./dorssel &lt; dorssel.c | ./dorssel</code></pre>
<h3 id="notice-to-those-who-wish-for-a-greater-challenge">NOTICE to those who wish for a greater challenge:</h3>
<p><strong>If you want a greater challenge, don’t read any further</strong>:
just try to understand the program without running the command below.</p>
<p>If you get stuck, come back and run the following command:</p>
just try to understand the program without running the command below.
If you get stuck, come back and read the below.</p>
<p>The file <a href="dorssel.html">dorssel.html</a> contains all the information needed to
understand this program.</p>
<p>For more information you might also try:</p>
<pre><code> ./dorssel &lt; dorssel.md</code></pre>
<h3 id="notice-to-those-who-wish-for-a-greater-challenge-1">NOTICE to those who wish for a greater challenge:</h3>
<p><strong>If you want a greater challenge, don’t read any further</strong>:
just try to understand the program via the source.</p>
<p>If you get stuck, come back and read below for additional hints and information.</p>
<ul>
<li>The file <a href="dorssel.html">dorssel.html</a> contains all the information needed to
understand this program. For spoiler information, try:</li>
</ul>
<!--
Copyright © 1984-2024 by Landon Curt Noll. All Rights Reserved.