David Mathog wrote:
Do any of you happen to have links to compendiums (or heaven forbid, an
actual manual) which maps compiler warnings and errors to examples of
actual code problems? In this case I'm specifically looking for one
for gcc. The general problem is of course that the compiler messages
must be short, and that tends to make them so cryptic that it isn't
always immediately obvious what the problem is. It almost makes me long
for the days when the IBM compilers would describe the problem with just
a number - which wasn't useful in and of itself, but was quite helpful
given the umpteen page messages manual which contained excellent
descriptions of each problem, indexed by that number.
Back in Bright College Days, a couple friends managed to
patch the FORTRAN compiler so that the text of every error
message was the single word "WRONG." But they showed mercy by
leaving the message ID intact, so you saw "NA201E - WRONG" and
could at least go to the manual and look up NA201E.
Anyway, this comes up (again) because I just figured out that the gcc
error:
foo.c:351: error: two or more data types in declaration specifiers
Which was cited for this line (the first prototype):
void handle_message( char *string);
was actually the result of the immediately preceding struct definition:
struct datastructure{
int this;
int that;
/*etc. all valid *
}
^ note the missing semicolon after the closing brace.
A couple of FAQ answers come pretty close to diagnosing this
problem, although none seems to get exactly this manifestation.
In this instance the message was not completely devoid of useful
information, since it at least localized the issue to the vicinity of
line 351, even if the actual error was on the first non blank line
preceding it. The message though - not too helpful. Why not "did not
find expected semicolon"? For this particular message google wasn't
all that helpful - in the first few results it turned up examples of the
message but not an explanation of what caused it.
It's perhaps a bit too much to ask that the compiler diagnose
the problem as "missing semicolon," since inserting a semicolon
is not the only transformation that would make the source valid.
For example, "extraneous `void'" is equally plausible, since
removing `void' would produce a valid declaration. In general,
a given invalid source may be "near" in an edit-distance sense
to several different valid sources, so describing the error in
terms of "the" correction that would fix it amounts to choosing
between those valid alternatives -- which amounts to reading the
programmer's mind.
I take some pleasure in the activity of pondering a c.l.c.
question and trying to answer it in the questioner's terms. This
involves looking behind the question itself and trying to imagine
what confusion or misconception led the questioner to ask it, and
then to come up with an explanation that addresses the underlying
problem. Thus, "You forgot to allocate space for the string's
terminating zero" instead of "Add one to the malloc() argument;"
the latter answers the "How do I fix it?" question, but the
former is more helpful. I think our computers will continue to
emit messages of the latter kind for the foreseeable future,
and that messages of the "sympatheti c analysis" kind will remain
the province of humans who learned the hard way.
--
Er*********@sun .com 
