Lambda the Ultimate

VB6 sometimes produces the error "Undefined Type", displayed in a message box without providing any context whatsoever (no name for the offending type and no location, not even the name of the source file - it could be anywhere in the project).
As a response you get to click "Ok" and the compilation aborts.

Disclaimer: I don't use VB6 out of personal choice ...

Thanks, g++!

Notable: GHC's "Expression has type a, expected type a"

... would have been a better title.

Anywayz, here's my own small (ocaml) pearl:

This kind of expression is not allowed as right-hand side of `let rec'.

Fortunately, these days we can google for quick fixes.

Overheard from an overworked student in a C++ course:

Microsoft VC++: Ambigious Error
Student: Oh, I'm ambigious?!!

Way back in the old days, when I was in junior high school, I entertained myself by learning C with my trusty second-hand copy of Turbo C++ 1.0. I hadn't grasped yet that a switch statement could only switch on something of integer value, and so tried something of the following seemingly reasonable (at the time) form:

switch(someString)
{
case "someValue":
{
/* Do something */
break;
}

default:
{
/* Complain */
break;
}
}

Anyway, what I got out of the compiler was "Non-integral switch expression." Not being immediately able to decode the meaning of this error, I decided to look it up in the manual. Borland's crystal clear explanation of the matter: "The switch expression you have attempted to use is not integral."

My greatest moment of aggravation with a compiler was actually due to the absence of an error message.

The C++ standard says "no length limits on names". Borland C++ 3.0 said "the length limit is 255 characters", which was pretty reasonable. But, in fact, the Borland linker had an undocumented limit of 63 characters--and, of course, this was on the munged name. So it was relatively easy (especially if you were using long names and/or nested classes) to hit the 63-character limit.

Now, if the compiler had thrown up an error message when it hit this limit, that would have been OK--a minor irritation, but usually a pretty easy one to work around.

It didn't. It just truncated the munged name to 63 characters.

Now, that's bad enough; but, in practice, the first 63 characters were often unique, so it could have worked. The problem was that, when the compiler called a function with a truncated name, it didn't pass any parameters on the stack.

Mind you, there was no reciprocal bug in the code generation for the function with a truncated name; it was still trying to read the parameters off the stack. If one of these parameters (say, the implicit this) was a pointer, the function then went on to trash memory. Since this was on Windows 3.1, this almost always meant at least a reboot, sometimes a reinstall.

It took me quite a while to figure out what was going on; I wound up having to inspect the generated assembly code. I submitted a bug to Borland, but, oddly enough, I never heard back. ;-)

PL-6, the system programming language of the old Honeywell CP-6 Operating System had a most useful message that would occur from time to time:

"Error found between beginning and end of file."

Fortunately, once you found someone who knew what was wrong, it was fairly easy to fix. But the first time you saw this you weren't too pleased. You usually went chopping code out until you found the offending area and then deduced what was wrong. [BTW, it was an incorrectly called macro without a trailing semicolon, most times]

And, no, the manual was of no use. It just said that your code had errors.

{Show {fun {$ X X} foo end bar baz}}

The Oz Emulator says:

%**** Error: conditional failed *****************
%**
%** Missing else clause
%**
%** Matching: baz

As VB and ActiveX were already mentioned, and parsers in fact are pretty close in spirit to compilers' lexers...

org.xml.sax.SAXParseException: The processing instruction target matching "[xX][mM][lL]" is not allowed.

Cause unidentified, the problem disappeared without changing the input file.

CMUCL once gave me an error something like

Error: 42 is not a number.

This was due to a type-inferencing bug incorrectly deciding that a variable could never be bound to a number at a certain point and that a runtime type-error should be signalled without checking the value.

Ken Thompson is known for parsimonious error messages. (The ubiquitous "?" from ed is [in]famous.) He mentioned a (FORTRAN?) compiler once (mercifully never released) that produced only two syntax error messages: JIM and JOE, for "Junk In Middle" and "Junk Off End".

APL\360 occasionally produced "nonce error", which was its abstruse way of saying that what you typed was legal, but the implementation wasn't capable of handling it. If you've seen Duff's Device you might understand why I know this.

Core Dumped.

:)

Seen from GCC.

Actually, the annoying messages are the warnings that a) are of constructs which are *perfectly* harmless, and b) can't easily be disabled. In a shop where the coding standard calls for no warnings allowed, such are annoying.

We see this in the PL community as well in how we implement our tools, but, perhaps, you were hinting at this already. It's an interesting (flame-baiting?) fine line.

Back on topic, there are two recent projects I found interesting in this space:

1. seminal: http://www.cs.washington.edu/homes/blerner/seminal.html

2. clarify: http://portal.acm.org/citation.cfm?id=1250747

EDIT: this was meant to be a reply to Ehud.

That was the error produced by the Honeywell 200 COBOL compiler upon reading my student's card deck. In fact, that was the entire output from the compiler; no listing; no hint as to which name was missing.

We riffled through the card deck, reading the interpretation (equivalent of the punched data, printed at the top edge of each card -- hardcore geeks in those days read the holes, but he was a student and I was lazy). Everything appeared in order. Suspecting a possible glitch in the card reader, we ran the compile again.

OBTW, this was a tape-based system, with 8K characters of memory and four mag tape drives. So compiling a program meant mounting the compiler tape (with the write-protect ring removed, of course), along with three scratch tapes, putting your source deck in the card reader, and booting the computer from the compiler tape. After much blinking of console lights lights and spinning of tape drives, again the line printer coughed out a page with a single error message.

Another quick riffle, scanning the interpreted printing, offered no clues.

The student admitted to having worked on his assignment during slack time at his job (a local bank service bureau), including punching at least some of the cards there. Suspecting possible misalignment in one or more cards, I had the student reproduce the deck on one of our state-of-the-art Univac electronic interpreting key punches. An unreadable card would have stopped the device. A successful duplication of the deck would have eliminated any slight out-of-tolerance problems, since we used that keypunch with that computer on a daily bases without encountering this kind of glitch.

Another compile, another one-error-message result.

Stubbornly riffling through the new source deck, I was surprised by a blank card where there should have been a section header! We went back to the student's original deck and discovered that the card in question had been printed with the correct source statement, but contained no holes! (Of course, it was one of the cards he had punched at work.) Although we never discovered the reason that the card had not been properly punched, replacing the blank card with a correctly-punched one allowed the compiler to do something meaningful with his program.

Not only is this my favorite example of a useless error message, it is my only known example, in forty years of programming, of a compile-time error triggered neither by an error in the source code nor in the compiler, but in hardware not part of the system compiling the program.

Archaeological footnote: the description of "8K characters of memory" is neither sloppy terminology nor senility. The Honeywell 200 series (partial clone of the IBM 1400 architecture) treated 8-bit units of memory as a one-bit "record mark", a one-bit "word mark", and six bits of data. Therefore memory was conventionally described as "characters" instead of "bytes". The record and word marks were used to group character data into two-level hierarchical data structures, supported by the machine code. Of course, that was back in the day when almost all manufacturers custom-designed their CPUs, so the idea of a "clone" was slightly disreputable...

I was doing some Fortran work on a mainframe years ago and I got the message THIS LINE WILL TERMINATE. Alas I did not work out in time that the message didn't come from the compiler, it came from the systems guys, who were about to disconnect my terminal.

java.lang.Error: bad Christian! no cookie!
          at * stack trace about 100 frames deep *


In the early OVM days, James Liang and Christian Grothoff sometimes sparred. Deep deep inside of the runtime system, under some very rare circumstance, James defended himself against Christian with this gem.

By FAR the most irritating error I've ever encountered is from javac. For instance if you want to return from a function early as part of debugging, you'll find you can't:

public void foo() {
  int a = 3;
  return;
  int b = 4;   // error
}

But if you write it like this:

public void foo() {
  int a = 3;
  if (true) return;
  int b = 4; 
}

It works! JavaC is such a stupid compiler it really is aggravating (and yes i know it's because the VM is supposed to do all the heavy lifting)

In the mid-80's, I was the QA person for LightspeedC and Lightspeed Pascal for the Macintosh (which later was renamed to ThinkC and ThinkPascal.)

What I did, was look at every error message and wrote sample code that would generate the error. After creating a substantial body of malformed code for testing. If I thought the error message wasn't clear, I would say so and push for improvements.

Furthermore, it was a small leap to create an error message appendix with useful examples and brief, but non-redundant explanations. Some explanations were a sentence or two, but others such as "Syntax Error" would run several pages illustrating the various causes of that annoyingly vague error message.

My first effort with LightspeedC, yielded 26 page appendix. My second effort resulted in a 66 page (8.5x11) appendix. This appendix was greater in size since Pascal is a more complex language and I had developed greater confidence.

Part of what I was also trying to achieve was a reduction in customer support calls too.

Why can't this be done more often?

invalid conversion from 'int(*)()' to 'int(*)()'

Reading this thread has me half tempted to replace all error messages in BitC with the string "type error". This is a context dependent error. Depending on context it either means that you typed something wrong or that something was wrongly typed... :-)

Many years ago on Usenet, someone posted a list of favourite error messages from Apple's old MPW C compiler...

• "String literal too long (I let you have 512 characters, that's 3 more than ANSI said I should)"
• "...And the lord said, 'lo, there shall only be case or default labels inside a switch statement'"
• "a typedef name was a complete surprise to me at this point in your program"
• "'Volatile' and 'Register' are not miscible"
• "You can't modify a constant, float upstream, win an argument with the IRS, or satisfy this compiler"
• "This struct already has a perfectly good definition"
• "This onion already has a perfectly good definition"
• "type in (cast) must be scalar; ANSI 3.3.4; page 39, lines 10-11 (I know you don't care, I'm just trying to annoy you)"
• "Can't cast a void type to type void (because the ANSI spec. says so, that's why)"
• "Huh ?"
• "can't go mucking with a 'void *'"
• "we already did this function"
• "This label is the target of a goto from outside of the block containing this label AND this block has an automatic variable with an initializer AND your window wasn't wide enough to read this whole error message"
• "Call me paranoid but finding '/*' inside this comment makes me suspicious"
• "Too many errors on one line (make fewer)"
• "Symbol table full - fatal heap error; please go buy a RAM upgrade from your local Apple dealer"

... it's claimed that an MS-DOS port of Awk once existed that had the error message "Not enough memory to do jack: terminating".

It's not a compiler error, but the famous HODIE NATUS EST RADICI FRATER surely belongs in any compilation (ha!) of famously unhelpful errors.

Since others have contributed somewhat off topic errors, let me add a favorite of my own. Compiler writers who have spent long hours with the Intel instruction set reference manual may have noticed this wonderful description of a potential error state when executing the PUSHA instruction, which saves several important registers to the stack:

In the real-address mode, if the ESP or SP register is 1, 3, or 5 when the PUSHA/PUSHAD instruction is executed, the processor shuts down due to a lack of stack space. No exception is generated to indicate this condition.

This is, perhaps, the least helpful error message possible. Also, what if ESP is 2 or 4?

Not "most annoying", but worth mentioning:

"Control level closure leaves gaping wound in control stack."

-- Clipper 5.0 compiler

This could happen when control structures (e.g. IF/ENDIF) weren't properly closed.

I didn't see anyone mentioned ie's javascript messages:

object expected

Upgraded my Ubuntu install from 8.04 to 8.10, which included a new version of GCC (4.3.2), one which adds (more) support for the forthcoming C++0x standard.

My code uses some nonstandard but ubiquitous parts of the standard template library--hash_set and the like--which are being standardized by c++0x, under the name unordered_set.

So when I compile under 4.3.2, I get the helpful warning from the compiler all over the place:

#warning This file includes at least one deprecated or antiquated header which may be removed without further notice at a future date. Please use a non-deprecated interface with equivalent functionality instead. For a listing of replacement headers and interfaces, consult the file backward_warning.h. To disable this warning use -Wno-deprecated.

which I quickly determined to refer to hash_set.

So I modified my code to use the new, soon-to-be-standard library, and get:

This file requires compiler and library support for the upcoming ISO C++ standard, C++0x. This support is currently experimental, and must be enabled with the -std=c++0x or -std=gnu++0x compiler options.

The second warning I don't mind so much, especially if the implementation of the new standard isn't fully debugged. But deprecating something before its replacement is production-ready seems to be a Silly Thing To Do...