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:
1 parent
09b8244f2f
commit
b969a2c05d
2 files changed
+83
-72
No files matched your search
+77
-71
@@ -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:
|
||||
|
||||
|
||||
@@ -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
|
||||
|
||||
Reference in new issue
Block a user