| Some of the code here requires a little explanation, so descriptions of the code samples follow the links. For the Javascript programs, you can click on the link and actually run the program in your browser. |
|
Javascript code cry12a.html - a brute-force key crypto simulation Run this in your browser - click Start to run, click Time Update to see calculations. To look at the code, click menu item "View source code". num26.js - base-26 calculation object cry12a uses this object idif.js - a set of interactive display interface functions cry12a uses these functions |
|
C code catfx.c - a line-editing filter |
|
Metacompiler code example of the metacompiler language stripc.def - a parser that strips comments from C files the generated code for stripc.def stripc.c - the C version stripc.bas - PowerBasic version (note! this is machine-generated code! that's why it looks so crappy!) metacompiler run-time the symbol table functions symbs.c - C version symbs.fns - Rebl version (Rebl is a Basic pre-processor) examples of running stripc - C files with their comments removed: stripc.cx - stripc run on itself catfx.cx - catfx.c processed by stripc symbs.cx - symbs.c processed by stripc |
|
Javascript The Javascript program cry12a is part of a suite of test programs for crypto. It was designed to show how long it takes to generate all keys if you solved an encryption problem by brute force. The time is dependent on the key length and how many solutions the computer can generate per second. This version crudely simulates the generation of keys (and solutions) by displaying an odometer that cycles through the generation of all keys. It assumes the keys are alphabetic, consisting only of the capital letters A-Z. It starts at A and goes up to all Z's for however big the chosen key is. Thus, for a 3-letter key it would cycle from A to Z, then AA to ZZ, and then AAA to ZZZ. The maximum key size for the simulation is 26, the number of letters in our alphabet. Originally the minimum was 11, because the encryption algorithm I was working on required a minimum key of that size. It's surprising how long it takes to generate all keys even of that size. I later modified it to do a minimum key size of 3. Three alphabetic letters represent a search space of approximately 17,000 keys -- this would take just a few seconds to run on a modern PC. On the other hand, a key size of 11 is a search space of roughly 3.7 quintillion, or 3.7 times 10 to the 15th power. Even at a rate of a million a second, the program tells us it would take about 116 years to generate all possible combinations for a key of that size. |
|
C code The C program here, CATFX, is a command line filter which performs some of the simple functions of awk and sed. The user specifies a string of commands which the program executes on each line in sysin. The original program was created by one of my fellow programmers at an engineering company we both worked at. It was used to automate the build process for a very large system, approximately 2000 modules, roughly a million lines of code. The original, CATF, was written in Fortran and was designed to turn lists of file names into shell scripts -- for example, to turn "xyz.c" into "compile xyz". The author gave me permission to re-implement this program in C and extend its functionality, thus this extended version is called CATFX. |
|
Metacompiler code The metacompiler samples here represent both code modules I have hand-written as well as code that was machine-generated. The machine-generated code was, of course, generated by the metacompiler. That's what a metacompiler is -- a code-generating program. The hand-written code is parts of the run-time system for the metacompiler. The metacompiler code here includes both C and Basic versions of the target code. Also included here are some examples of running the stripc program to show that it works as advertised. It parsed the files stripc.c, catfx.c, and symbs.c to produce the same files with cx extensions (eg, stripc.cx) and with all their comments removed. As an interesting sidenote, one of the reviewers of this website recommended I use the stripc program on the C programs shown here, to show real working examples of the metacompiler and its products. When I processed the catfx.c program, the stripc program didn't strip all of the comments out of catfx. That is, it failed. I re-ran stripc using the built-in trace package and found where the error occurred -- it turns out I took care of scanning double-quoted strings in stripc, but I took a shortcut by not scanning single-quoted strings. In C, single-quoted strings are used for single characters. In most cases these can be treated as any other string of 3 or 4 operators. What I hadn't anticipated was that catfx single-quoted a double-quote character -- this resulted in the quoted double-quote starting a bogus string that offset all real strings in the file, thus landing all subsequent comments within the bogus strings. This error is hard to explain verbally, and one quick picture would explain it all handily, but the point is this -- stripc is code that is almost 10 years old, it had a bug, and I was able to trace the problem, pinpoint the bug, fix the tool (stripc), re-generate the tool, and re-generate the correct output. All in less than half an hour. That's pretty good, and is a tribute to the power of the metacompiler language for describing the problem domain. I have debugged simple parse errors through lex and yacc tables, and believe me, it is no picnic. |
e-mail address:
plt
|
| phone number: 714-921-9753 |