Format fix 2004/jdalbec/README>md + update todo.md

The todo.md file fix a format issue but I also added this entry to the
file: I'm just too tired right now to bother doing it.
This commit is contained in:
Cody Boone Ferguson committed 2023-04-26 05:11:50 -07:00
1 parent 09b8244f2f
commit b969a2c05d
2 files changed
+83 -72

No files matched your search

+77 -71
View File
@@ -1,8 +1,6 @@
# Best Abuse of the Periodic Table
John Dalbec
20 Squire's Ct.
Canfield OH 44406
US
<https://jpdalbec.people.ysu.edu>
@@ -36,47 +34,52 @@ it's the first atomic fission we've seen in the IOCCC.
It's elementary!
See <http://mathworld.wolfram.com/LookandSaySequence.html>,
<http://mathworld.wolfram.com/CosmologicalTheorem.html>,
and the references listed there.
See <http://mathworld.wolfram.com/LookandSaySequence.html> and
<http://mathworld.wolfram.com/CosmologicalTheorem.html> and the references
listed there.
Go read the web pages and come back.
This program implements the look-and-say sequence with the
added feature that each "decay product" is automatically split
into its constituent "elements" separated by spaces. Furthermore,
arguments passed to the program are treated as separate elements
for the purpose of computing further decay products. (Compare
the output of "prog 1", "prog 11", and "prog 1 1".) This
allows output lines from the program to be passed back to the
This program implements the [look-and-say sequence (one of the above listed
links)](https://mathworld.wolfram.com/LookandSaySequence.html) with the added
feature that each "decay product" is automatically split into its constituent
"elements" separated by spaces. Furthermore, arguments passed to the program
are treated as separate elements for the purpose of computing further decay
products. (Compare the output of `./jdalbec 1`, `./jdalbec 11`, and `./jdalbec
1 1`.) This allows output lines from the program to be passed back to the
program as input (minus the initial generation number).
The common elements are listed in CosmologicalTheorem.html.
The non-primordial transuranic elements are the isotopes of
Neptunium and Plutonium. Isotopes of a given element differ
only in the last digit. Four common elements could also be
written as isotopes of these two elements: He=Np(2), Li=Pu(2),
Ta=Np(3), W=Pu(3). To get other isotopes, just change the
last digit to a number greater than 3.
The common elements are listed in
[CosmologicalTheorem.html](http://mathworld.wolfram.com/CosmologicalTheorem.html).
The non-[primordial](https://en.wikipedia.org/wiki/Primordial_nuclide)
[transuranic elements](https://en.wikipedia.org/wiki/Transuranium_element) are
the [isotopes](https://en.wikipedia.org/wiki/Isotope) of
[Neptunium](https://en.wikipedia.org/wiki/Neptunium) and
[Plutonium](https://en.wikipedia.org/wiki/Plutonium). Isotopes of a given
[element](https://en.wikipedia.org/wiki/Chemical_element) differ only in the
last digit. Four common elements could also be written as isotopes of these two
elements: `He=Np(2)`, `Li=Pu(2)`, `Ta=Np(3)`, `W=Pu(3)`. To get other isotopes,
just change the last digit to a number greater than 3.
The build file runs prog.c through the C preprocessor to
generate prog2.c which is edited with ed to correct spacing
The build file runs [jdalbec.c](jdalbec.c) through the C preprocessor to
generate `jdalbec2.c` which is edited with `ed(1)` (NOTE: this was
changed to `sed(1)` by the judges) to correct spacing
problems caused by some preprocessors. (I know you dislike
Perl, but hopefully ed is more common on POSIX systems than
Perl.) The build file then compiles prog2.c and removes the
prog2.c file.
Perl, but hopefully `ed(1)` is more common on POSIX systems than
Perl.) The build file then compiles `jdalbec2.c]` and removes the
`jdalbec2.c` file.
I don't think I'm abusing the build file since I'm only using
147 characters including white space and the #! line and the
commented-out "-Wall -pedantic" options. The rules for the
16th IOCCC rules specifically allowed build files up to 521
I don't think I'm abusing the [Makefile](Makefile) since I'm only using
147 characters including white space and the `#!` line and the
commented-out `-Wall -pedantic` options. The [rules for the
16th IOCCC](/2004/rules.txt) specifically allowed build files up to 521
characters long so my build file would have been well within
those limits. (What typo?)
gcc -E -Wall -pedantic complains that trigraphs are present and that
"pasting ... does not yield a valid processing token".
`gcc -E -Wall -pedantic` complains that trigraphs are present and that
`"pasting ... does not yield a valid processing token"`.
gcc -ansi -Wall -pedantic complains about #line directives,
`gcc -ansi -Wall -pedantic` complains about `#line` directives,
trigraphs, and expressions and statements that have no effect.
The last complaint is false in all but one case. Removing
the offending expressions causes some compilers to report
@@ -85,7 +88,7 @@ refers to a variable or a type.
Since buffer overflows are a common security problem these
days I have stolen the idea of using a "safe" buffer API from
vsftpd. This means the program should never crash, right?
`vsftpd`. This means the program should never crash, right?
The program was tested on:
AMD K6/MMX 266MHz, Debian GNU/Linux testing "Sarge", gcc 3.3.2
@@ -97,78 +100,81 @@ Sun SPARC Ultra 10, Solaris 8, gcc 3.2
Compiling on Mac OS 8.6 requires some degree of manual
intervention because Mac OS 8.6 doesn't have shell scripting
or even a normal command prompt. The CodeWarrior 11 compiler
or even a normal command prompt. The `CodeWarrior` 11 compiler
is the reason I had to use trigraphs. I have to preprocess
prog.c without trigraphs, save the result as prog2.c, then
compile prog2.c with trigraphs to get the program to work.
`jdalbec.c` without trigraphs, save the result as `jdalbec2.c`, then
compile `jdalbec2.c` with trigraphs to get the program to work.
I also have to add an include file and a function call to the
program to get a pseudo command line so I can pass arguments.
The compiler also requires function prototypes by default,
which is why I have prototypes for all my functions.
Compiling on Mac OS X 10.1.5 requires changing ??= to \# on
line 3 because the compiler doesn't recognize ??= as a trigraph
Compiling on Mac OS X 10.1.5 requires changing `??=` to `#` on
line 3 because the compiler doesn't recognize `??=` as a trigraph
(which I consider a compiler bug). The initial preprocessing
step on Mac OS X 10.1.5 generates lots of errors in "smart
mode" because the "smart" preprocessor expects a valid C
program as input. The preprocessor then falls back to "basic
mode" and preprocesses prog.c successfully without warnings,
even when I give it the "-Wall -pedantic" options. It inserts
mode" and preprocesses `jdalbec.c` successfully without warnings,
even when I give it the `-Wall -pedantic` options. It inserts
a lot of extra spaces into the preprocessed output which is
why I had to add the "ed" step to the build file so that my
macro #defines would work. The compile step gives the usual
messages with "-Wall -pedantic". The link step generates a
warning about a name conflict between my BC() and a BC() from
why I had to add the `ed` step to the build file so that my
macro `#defines` would work. The compile step gives the usual
messages with `-Wall -pedantic`. The link step generates a
warning about a name conflict between my `BC()` and a `BC()` from
curses in the main system library.
BUGS, I mean FEATURES:
Arguments matching /[^2]22$/ cause the program to segfault
### <strike>BUGS</strike> FEATURES:
Arguments matching `/[^2]22$/` cause the program to segfault
after rapidly exhausting the available stack space. I could
probably fix this by adding some special cases to the code,
but [Blaine the Mono] it's quite a bit more exciting this way,
don't you think?[/Blaine] Since the trailing "22" will be
don't you think?[/Blaine] Since the trailing `22` will be
its own atom anyway, you can just insert a space in front of
it if you run into this feature (e.g. "1 22" instead of "122").
it if you run into this feature (e.g. `1 22` instead of `122`).
Note: you may want to be sure you have a limit on stack size
before trying this. I ran it on Debian GNU/Linux and discovered
that I did not have a limit on stack size. Fortunately the
OS killed the process after a while. This is consistent with
the output of 1996/schweikh3 which reports "malloc lied!
Killed by SIGKILL".
Note: you may want to be sure you have a limit on stack size before trying this.
I ran it on Debian GNU/Linux and discovered that I did not have a limit on stack
size. Fortunately the OS killed the process after a while. This is consistent
with the output of [1996/schweikh3](/1996/schweikh3/schweikh3.c) which reports
`malloc lied! Killed by SIGKILL`.
Arguments matching /(?:.){10,}/ will produce visually incorrect
Arguments matching `/(?:.){10,}/` will produce visually incorrect
results (e.g., generation 1 starting from 1111111111 will
print as ": 1"), but there's nothing interesting about these
print as `: 1`), but there's nothing interesting about these
arguments that can't be modeled using shorter runs of the same
symbol.
Arguments matching /(?:.){257,}/ may produce mathematically
Arguments matching `/(?:.){257,}/` may produce mathematically
incorrect results (e.g., generation 1 starting from a string
of 257 1's will be calculated as "11"); the remark from the
of 257 `1`s will be calculated as `11`); the remark from the
previous paragraph applies here also.
The program has exactly 2004 IOCCC countable bytes. It's
tailor-made for this competition!
Although there are no comments, the program still manages to
be self- documenting in an obscure fashion (periodic table of
be self-documenting in an obscure fashion (periodic table of
the (non-primordial) elements, "OBFUSCATED C").
### Obfuscation
The program is obfuscated:
By invoking cpp twice
By the use of #defines
By the use of typedefs
By the use of global constants
By the use of global functions that replace the standard ones (I
particularly like substituting At (Astatine, highly unstable) for abort.)
By overloading symbols (For example, B is a type, a structure, a structure
member, a macro parameter, and a variable.)
By standard tricks like writing '\0' as 1["3"] or 2["22"]
By using ternary operators to avoid "else"
By using the Sb function to create subbuffers from either end
By naming everything after chemical elements or pairs of elements
Because it says so in the source. ;)
- By invoking `cpp` twice.
- By the use of `#define`s.
- By the use of `typedef`s.
- By the use of global constants.
- By the use of global functions that replace the standard ones (I particularly
like substituting `At` ([Astatine](https://en.wikipedia.org/wiki/Astatine),
highly unstable) for `abort()`.) By overloading symbols (For example, `B` is a
type, a structure, a structure member, a macro parameter, and a variable.).
- By standard tricks like writing `'\0'` as `1["3"]` or `2["22"]`.
- By using ternary operators to avoid `else`.
- By using the Sb function to create sub-buffers from either end.
- By naming everything after chemical elements or pairs of elements.
- Because it says so in the source. ;)
## Copyright and CC BY-SA 4.0 License:
+6 -1
View File
@@ -9,12 +9,16 @@ track of things that have been done already and what have not been done (mostly
not been done).
- Find entries with bugs and INABIAF and add to [bugs.md](/bugs.md).
For instance a INABIAF section should be added to [bugs.md](bugs.md) for
[2004/jdalbec](2004/jdalbec/jdalbec.) based on the README.md file.
- Resolve as many of the issues in [bugs.md](/bugs.md) with the exception of the
INABIAF ones. This is likely not possible but some certainly can be fixed.
- Check for typos in README.md files.
- Verify which README.md files have not been checked for correct formatting and
fix any issues.
* This includes author information: not only at first column but making sure
that the lines end with spaces so that the rendered output does not end up
on one line only.
@@ -25,6 +29,7 @@ fix any issues.
been checked except that a few years might need typo checks (or a bit more
thoroughly). It's very likely I won't keep this updated until it's finished
but I wanted to note it now.
- Remove addresses from older winning entries but (if known) keep country code +
add country code to winners.csv. As of half past 4 Pacific time on 22 April 2023
only the years through 1986 are done. This should not take much time but I