Files
ioccc/2005/mikeash
Landon Curt Noll ecabb73bf6 add tools to compare entry's manifest with its files
Added `bin/bin/tar-entry.sh` to build a compressed tarball for an
entry.  The compressed tarball is formed by gnu tar with options
so that the same entry file content will always produce the same
compressed tarball, byte for byte.

As some files are missing from some entries, one should
use the `-W` option as in:

```sh
bin/tar-entry.sh -v 5 -W 2020/ferguson1
```

Added `make form_entry_tarball` to the top level `Makefile`
to build entry tarballs even when files are still missing.

Added `make verify_entry_files` to verify that all entries have all
of their files listed in their manifest, plus the top level ioccc.css
and var.mk files.  As file entry files are still missing (due to
HTML files that need to be built), the overall `make quick_www` and
`make www` do **NOT** (yet) exit when the `make verify_entry_files`
fails.

Improved `bin/chk-entry.sh` by removing some variables
that were not needed.

TODO: Improve `bin/` tool exit codes as the current use is a bit silly.

TODO: Clean out some variables used in `bin/` tools as some of then
are only set printed in debug statements.

TODO: Clean up usage messages, some of the options listed to not
match the `getopts(1)` parsing.  In some cases the option needs to
be parsed but needs to be ignored by the tool because another tool
automatically passes along certain options that really have no
effect.  Such ignored options need to be show as "This option is
ignored" in the usage message.
2024-02-13 03:29:54 -08:00
..
2024-02-01 14:35:49 -08:00
2023-12-26 09:00:03 -08:00
2023-07-07 06:55:42 -07:00
2023-07-06 21:49:38 -07:00
2024-01-15 04:29:39 -08:00

To build:

make

Bugs and (Mis)features:

The current status of this entry is:

STATUS: INABIAF - please **DO NOT** fix

For more detailed information see 2005 mikeash in bugs.md.

To use:

./mikeash

NOTE: the author stated that they tested this under i386 machines but this works under 64-bit (x86_64, arm64) machines too.

Try:

./try.sh

Judges' remarks:

Having problems speaking code? Do you LISP? Parenthetically speaking, this entry takes advantage of C99 features, while speaking parenthetically. Best of all, it self-reproduces!

John McCarthy might not have imagined it quite like this! :-)

Author's remarks:

This program is a self-reproducing program, which is on the IOCCC's list of discouraged program types. Worse, it's a self-reproducing program written in Common Lisp. What's this doing as an entry to the IOCCC?

Start over: this program, when compiled with a C99 compiler, is an interpreter for an extremely limited and highly broken subset of Common Lisp.

It requires C99 because of C99's ability to declare variables in the initializer of a for loop. Unfortunately, C99 mode typically warns about implicitly declared functions, and preprocessor directives prevent the program from being valid Common Lisp. As a result, several warnings will be printed about implicit declarations of functions. There are also warnings about unknown escape sequences in the constant string, due to different string escape semantics in C and Lisp, and some implicit integer-to-pointer conversions due to the implicitly-declared functions.

Try:

echo '(format t "~s" (+ 2 2 ))' | ./mikeash

You should see 4" echoed on your command prompt. The " after the 4 and the lack of a newline are due to the somewhat broken implementation of the format function. More sophisticated arithmetic expressions may be used:

echo '(format t "~s" (* (+ 2 2 ) (- 5 (/ 9 3 ))))' | ./mikeash

This evaluates the expression (2+2) * (5 - 9/3) giving the correct result, 8" (with the same issue of no newline after the "). Note that due to the highly ad-hoc nature of the tokenizer, the spaces before the closing parentheses are mandatory.

The program can also be run in an interactive mode, by simply executing ./mikeash and then typing lisp expressions, but this is difficult due to the lack of proper editing facilities and the total lack of error recovery in the interpreter. Typos will most likely crash the program.

Aside from being required to put spaces between tokens and closing parentheses, there are other limitations on the dialect of Common Lisp that this program understands:

  • The only built-in functions are defvar, format, substitute, char-upcase, +, -, *, and /.

  • Only one variable is available. This variable is called q, although any symbol name starting with the letter q will be mapped to this variable.

  • Only the first letter of a function name is significant. For example, format, f, farm, and various other words starting with f will all map to the format function.

  • The defvar function completely ignores its first parameter. It will always store the result of evaluating its second parameter in q. Unlike in Common Lisp, multiple invocations of defvar on the same variable will overwrite old values.

  • Character constants are limited to #\Newline and single-character constants such as #\x.

  • The char-upcase function will give strange results if passed something other than a lowercase character.

  • The format function takes exactly three parameters. The first parameter is ignored; output always goes to stdout. The second parameter must have exactly one ~s format specifier in it, and no other format specifiers are permitted.

  • The arithmetic functions take exactly two parameters.

  • All tokens must be separated from a following ) by whitespace.

  • A lot of other things. Notably, the language which this program interprets is nowhere near Turing-complete.

Basically, the LISP interpreter is good for some basic math operations, and for running itself. To do the latter, try this:

./mikeash < mikeash.c > mikeash2.c
diff mikeash.c mikeash2.c

The program can also be run from an implementation of common lisp. To do this, run the common lisp compiler and then type the following command:

(load "mikeash.c")

The source code of mikeash.c will be printed.

Obfuscation

Lispob is obfuscated in several ways. First, it's actually two programs in one, which actually share a small amount of code. Running a C code beautifier will destroy the LISP program contained within. Second and more importantly, it is very badly written, which will presumably confuse people who are used to looking at well-implemented interpreters.

The program comes in at just under 2k of significant characters. However, this size is exaggerated, because it contains a complete copy of itself for the self-reproducing LISP program, making it twice the size. This doubling effect made it something of a challenge to fit inside the IOCCC's size limit.

This code should be highly portable. It was tested under Mac OS X and Linux on i386, but it should run elsewhere. It requires ASCII due to hardcoding various character constants. Other than this requirement, it should run anywhere there's a conforming C99 compiler and a standard C library.

This file is Copyright (c) 2023 by Landon Curt Noll. All Rights Reserved. You are free to share and adapt this file under the terms of this license:

Creative Commons Attribution-ShareAlike 4.0 International (CC BY-SA 4.0)

For more information, see: https://creativecommons.org/licenses/by-sa/4.0/