--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/interps/c-intercal/BUGS	Sun Dec 09 19:30:08 2012 +0000
@@ -0,0 +1,67 @@
+			BUGS
+
+There are still some known bugs in INTERCAL (and no doubt many we don't even
+suspect as yet).  The following list accumulates current bug reports and
+TO DO agenda items through the current release.
+
+ESR = Eric S. Raymond
+SS  = Steve Swales
+LHH = Louis Howell
+BLR = Brian Raiter
+AIS = Alex Smith
+
+1) (ESR) INTERCAL would be intrinsically a crock even if it worked right.
+
+2) (BLR) I have hacked up a fix to the problem with line numbers being off
+   due to statements sharing/spanning lines. The parser now stores the
+   starting line number for all tuples, not just the splatted
+   ones. Not only does this give synchronized lines in the comments in
+   the degenerated C code, but run-time error messages are just as
+   reliable as the parse/compile-time ones. The line number in the
+   error message is actually the line number of the next statement
+   (e.g., if the next statement is on the same line, the line number
+   of both statements will be used).
+
+   Note that I said "just as reliable," as opposed to "fully
+   reliable". Since the lexer doesn't know where the line ends until
+   after it's already parsed the preamble (DO-PLEASE combo, line
+   label, oh-oh-seven number, etc) of the following line, it actually
+   stores as the starting line number the first non-whitespace of the
+   statement proper. So if a statement has its preamble on one line
+   and the rest of it on the next, the preamble will be beheaded.
+
+   Still, it's a vast improvement, and as LHH pointed out, it's not
+   going to get much better without writing a preprocessing lexer that
+   can actually separate out the statements before any real parsing
+   begins. Until someone wants to do that, this will do nicely, I think.
+
+   As a side bonus, splatting now shows the entire statement. (Er,
+   except when the statement both spans and shares a line. If a multi-
+   line statement ends on the same line as the beginning of the next
+   statement, the last part will get truncated. Again, not a case we
+   want to be encouraging people to explore anyway.)
+
+3) (BLR) Interleave does not check the type of its arguments. The manual
+   insinuates that interleaving 32-bit values should result in error 533;
+   instead, C-INTERCAL silently truncates them to 16 bits. Unfortunately,
+   the modified behavior of select's return type depends on this, so
+   there's not much we can do about it as things stand.
+
+4) (AIS) Reverse assignments (those with the expression on the left)
+   are very unlikely to work in bases other than 2. (The current code
+   calculates what the answer would be in base 2 and throws an error
+   if it isn't correct for the current base.)
+
+5) (AIS) Some of the newer features in intercal.el are not yet fully
+   implemented and have a tendency to print 'Unimplemented' rather
+   than doing anything useful.
+
+6) (AIS) The external call system only works with gcc (due to its need
+   to pass command-line arguments like -x and -E to it), and fails
+   when mixed with come-from-gerund and next-from-gerund.
+
+			TO DO
+
+1. (ESR) Add more optimization templates, esp. idioms for +, -, *, /.
+
+2. (ESR) Forget this @!%$#! crock and take a long vacation.