Compendiums of compiler warning/error messages mapped to actual codeproblems?

[David Mathog]

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.

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.

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.

Regards,

David Mathog

 

[Ed Prochak]

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.

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.

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.

Regards,

David Mathog

to answer your last question first, and in defense of compiler writers
everywhere:
It is not always possible to determine what is expected as the next
token in the input stream of the compiler. Keep in mind a good
compiler must accept all valid source code AND flag invalid code. The
point at which a compiler detects an error may be, as you know, far
from the actual cause of the problem.

aside from that, I think an errors manual written this way would be
very VERY helpful!
Ed

 

[David Mathog]

to answer your last question first, and in defense of compiler writers
everywhere:
It is not always possible to determine what is expected as the next
token in the input stream of the compiler.
Understood.

I think an errors manual written this way would be
very VERY helpful!

Long text strings aren't ideal indices. Imagine this blast from
the past:

gcc -Wcite_number ...

foo.c:351: error 43325: two or more data types in declaration specifiers

At which point it would be really easy to retrieve the desired
documentation. For instance if the gnu compiler folks were to support
the following hypothetical resource:

firefox "http://www.gnu.org/gcc/manual_by_number.html#43325"

Ditto for any other compilers and various other retrieval methods.
This might make an interesting Wiki, since even the compiler writers
can't be expected to know ahead of time all code situations which might
generate a particular error or warning.

This could still be done with the text messages, but since they
generally contain spaces those can't just be pasted into a URL.

Regards,

David Mathog

 

[Eric Sosman]

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 "sympathetic analysis" kind will remain
the province of humans who learned the hard way.

 

[jacob navia]

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.

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.

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.

Regards,

David Mathog

This is a quality of implementation issue...

For instance this program
struct datastructure{
int this;
int that;
}

int main(void)
{
}

provokes with lcc-win:
Error twarn.c: 6 missing semicolon after structure declaration
Warning twarn.c: 6 multiple use of 'int'
1 error, 1 warning

Better isn't it?

 

[Ben Pfaff]

For instance this program
struct datastructure{
int this;
int that;
}

int main(void)
{
}

provokes with lcc-win:
Error twarn.c: 6 missing semicolon after structure declaration
Warning twarn.c: 6 multiple use of 'int'

The warning here does not make any sense: `int' is only used once
in this declaration (except inside the struct definition--but
that's clearly not what the warning talks about).

 

[Martin Ambuhl]

This is a quality of implementation issue...

For instance this program
struct datastructure{
int this;
int that;
}

int main(void)
{
}

provokes with lcc-win:
Error twarn.c: 6 missing semicolon after structure declaration
Warning twarn.c: 6 multiple use of 'int'
1 error, 1 warning

Better isn't it?

Actually, it's an abomination. "Multiple use of 'int'" has no
relationship to the problem with this code. It is wrong and completely
unhelpful.

The gcc diagnostics for this code are much more to the point:

a.c:6: error: two or more data types in declaration specifiers
a.c:7: warning: return type of 'main' is not 'int'

There are numerous nice features of lcc-win. This bogus diagnostic is
not one of them.

 

[Richard Tobin]

It is not always possible to determine what is expected as the next
token in the input stream of the compiler. Keep in mind a good
compiler must accept all valid source code AND flag invalid code. The
point at which a compiler detects an error may be, as you know, far
from the actual cause of the problem.

Long ago I used an compiler in which almost every error message was
followed by the suggestion "missing semicolon?". It was often right.

-- Richard