“Sometimes GCC emits something that can be described as Haiku poems – and you have no clue as to what it really is complaining about. This page is a collection of such gems, their meaning in English and how to solve the problem.”
“Sometimes GCC emits something that can be described as Haiku poems – and you have no clue as to what it really is complaining about. This page is a collection of such gems, their meaning in English and how to solve the problem.”
Sometimes GCC emits something that can be described as Haiku poems
Cast to int implied
Data may be truncated
At least a warning
;}
They are programmer’s errors
Edited 2007-03-09 16:11
Yes, but sometimes a nicer and more precise error message would be helpful.
The most disturbing error messages I’ve seen so far are from accidentially feeding C++ code into gcc. Holy sh*t, if these error messages are not scary I don’t know what is! So if gcc tells you that your code doesn’t make any sense it’s probably because you should have called g++ in the first place.
Nevertheless, it should do some simple checks like running g++ (if it’s installed) on the same input and check if it produces less error messages. A simple hint like “You want to run g++ on this source” would be nice.
/me imagines Thom searching for Haiku-related news and stumbling across this…
Edit: Oh, it was submitted by someone else
Edited 2007-03-09 16:41
The more fun ones are template errors. Two pages of output and you still have no idea what you did wrong.
Yeah. Makes me nervous about the wth is going on with template code that compiles but isn’t 100% correct. And how many crashes all that ridiculous complexity has caused.
The more fun ones are template errors. Two pages of output and you still have no idea what you did wrong.
Well, you’re coding in C++, yes? There’s where you went wrong
lol
Write some moderately complex code using Boost.Lambda, then make a typo. Just one, in an innocuous a place as you can find. G++ will just barf all over your shoes, and you won’t be able to get the smell out for a week.
The complete illegibility of template expansion errors has killed any enthusiasm I had for Boost, or “modern C++” in general. Its not really the fault of the compilers, C++ templates are just a fundamentally crappy feature from an ease-of-use and ease-of-implementation point of view.
Edited 2007-03-09 21:36
I definitely have found Java to give more specific errors when there are compile problems – I think it is due to the degree of reflection in the language itself. I think that makes it an easier job for the compiler to spot errors.
It’s not the degree of reflection in the language, but rather the syntax and semantics of the language. Java is explicitly designed to be parseable with an LALR(1) grammar. Parsing C++ is nearly impossible with conventional parser generators that are designed for LALR grammars. Also, the template syntax is very poorly suited for use in meta-programming, because it wasn’t originally designed for that. It “evolved” from a simple generic programming facility into a meta-programming facility. When you combine all this with the fact that C++ tries very hard to maintain compatibility with the extremely primitive C linking model, you end up with the mess you have now.
It is entirely possible to design a macro (meta-programming) system that is powerful, simple, and relatively easy to implement. Between Scheme, Lisp, and Dylan, there are probably a couple of dozen good macro implementations in existence. In comparison, there are all of three C++ parsers that even come close to standards compliance, even despite the fact that there is probably a couple of orders of magnitude more effort put into C++ implementations than into implementations for those languages combined.
I’m going to use Dylan’s macro system as a point of comparison, since the prefix syntax of Scheme and Lisp make macros much simpler to implement and easier to understand. However, it should be noted that these points apply almost universally to macro systems in all of these languages. The first thing the Dylan designers did right with the macro system is make the language LALR(1) parseable, including the macro sub-language. This means that you don’t need to hand-write a complicated parser for the language, but you can instead use one of the array of tools that exist for dealing with LALR grammars. Second, they designed it explicitly for meta-programming, specified that basic syntactic constructs in the language (things like “for” loops) should be implemented as macros over more primitive constructs. This gave compiler writers a very strong incentive to make macro-expansion error messages really easy to understand, otherwise even simple syntax errors in loops would be incomprehensible. Third, Dylan compilers treat macros as first-class compile-time objects, and store a representation of the macro in the compiled output. Not only does this buy you the ability to export macros from shared libraries, but it gives the compiler a very clear separation between the single definition of the macro and uses of the macro. Fourth, and this is a point that ties back to the ease of implementation point, Dylan IDEs give you a way to see the code after macro-expansion. Almost all compile-time errors that result from calling a macro happen because the macro is used improperly in a way that causes invalid code to be generated. Looking at the expanded code usually makes it immediately obvious what you did wrong.
I actually like C++ templates and Boost quite a lot. It’s just the compiler errors that suck.
It’s much easier to find the bug by inspecting the code than reading the error.
Other compilers tend to give much more reasonable errors than gcc. There are even compilers who can give proper error messages with templates, whereas any gcc error message having something to do with a template just gives half of the screen full of text it can take an hour to digg through.
Also anyone remembers the error message given if you forget a “;” behind a class somewhere, or you want to declare some shiny iterator which is (why it has to is beyond my scape) in this form not allowed but needs a typedef? You have to store these messages somewhere in your brain or otherwise will never find the originating error
p.s.: I don’t like this article, it’s just only 3 random messages which are even rather understandable ones, too.
Edited 2007-03-09 17:38
The faulting class is not the one that GCC complains about but one of the classes included from the file containing the class declaration GCC nags you about. Locate the faulty class in one of the suspected files, add the semi-colon and try compiling again.
God forbid you have fifty such files… Is this a compiler problem that could be fixed, or a language issue?
It should be pretty easy to add an optional fatal warning if a class isn’t properly terminated by the end of a file.
their meaning in English
I’d prefer them in C with line and character numbers. Informative article but I don’t find gcc really all that cryptic by comparison, just need to take it literally sometimes and think from it’s perspective.
GCC 4.1 started complained about type punning in code that always compiled just fine before. I fixed it and moved on, and I don’t remember what the issue was. But I thought that was a very novel error message when I first saw it.
If GCC is so bad at producing legible error messages, why not offer the developers more appropriate messages instead of complaining? Be part of the solution, not the problem.
“If GCC is so bad at producing legible error messages, why not offer the developers more appropriate messages instead of complaining? Be part of the solution, not the problem.”
Personally, I like the concept of throwing a detailed error message containing some information:
– What error occured?
– Where did the error occur?
– What initiated the error?
This goes for gcc as well as for any other program. For example, instead of throwing “error 5”, something like “error: fopen(): file not found: /dev/foobar” would be the right way to inform the user about an abnormal termination.
A detailed and complete (!) explaination of the problem is the best way to get a solution. This is not “complaining”, it rather is “identifying the error as exact as possible”. The compiler is not the problem. The source code files passed to it are – or the ones who wrote it. 🙂
In most cases, the compiler can only judge from syntax, but not from context. It uses the description of the “skeleton” of the C programming language, but it cannot imagine what the programmer wants. Maybe you’re thinking about the semantic compiler? 🙂
int a, b, sum;
sum = a – b;
semcc: error in foo.c in line 5: You wanted a sum, but got a difference. Please change ‘-‘ to ‘+’. By the way, I fixed it for you…
Would that be more appealing? 🙂
(Excuse me if I’m doing you wrong. It’s typical for most users that they don’t know what they’re doing, but should we enlarge this way of doing things to programmers, too? ‘Trial and error’ is not a programming concept.)
Actually I’m not too bothered about the ‘discards qualifiers’ one; I had something similar from VC++ the other day that was much more obscure.
I forget the details, but the message made it sound like I was passing completely the wrong kind of variable as an argument, there was no clue that “const” was the issue.
Each compiler speaks their own dialect. Once you’ve encountered “control reaches the end” and fixed it, it’s never a problem again.
Unfortunately none of these dialects are the Queen’s English, but if someone invented a compiler that did speak it, lots of us would be out of a job 😉