tags:

views:

127

answers:

2

Is it possible to instruct GNU c++ compiler to stop after 5 errors found? Can't find this in documentation. Thanks in advance.

+3  A: 

I have to ask why you would want to do this. Sometimes the error that exists in the code is not the first or even found in the first five errors. Sometimes it's beyond that and only is recognizable once you scroll down the list. A better method might be to break up your code and place it into smaller libraries if you're bothered by compile times. Or if you're concerned with things scrolling off the screen of a command line, using the '>>' operator to pipe the messages into a file.

wheaties
It's just a matter of error log readability. 5 errors are more than enough to understand the problem, at least in my case :)
Vincenzo
Really? My experience has been just the opposite -- especially in C++, unless I'm doing specific sorts of refactoring work that create lots of discrete errors (changing the arguments to a commonly-used method, e.g.) the very first error is likely to be the only one that's any use at all.
Zack
@FaZend.com I see, I'm sorry I provided a non-answer then. Zack's answer below is probably the best you're going to get to unless you're going to write a small script to parse these error and kill the process after 5 errors are output. (although I might be quite ignorant in this statement.)
wheaties
Nevertheless, your output redirection answer is not bad. Combine it with e.g. the `head` utility and you can limit the amount of error messages. But note that tail measures in lines, and some error messages take more than one line.
Ben Voigt
+3  A: 

There's no way to get it to stop after the first five errors, but -Wfatal-errors will make it stop after the first one error (not warning, unless you also have -Werror, which you probably shouldn't). See http://gcc.gnu.org/onlinedocs/gcc-4.4.4/gcc/Warning-Options.html .

This option appears to have been added in GCC 4.0.

Zack
(I'm sure the GCC team would be happy to take a patch that made `-Wfatal-errors=N` stop after *N* errors... ;-)
Zack
I'd give this +1 but for the statement about `-Werror`. I believe that warnings absolutely *should* be treated as if they were errors, because most warnings are an indication of buggy code.
greyfade
@Zack, thanks, I'm using this flag already :)
Vincenzo
@greyfade, I also think warnings should generally be treated as must-fix, but unfortunately some of gcc's warnings may trigger or not depending on optimization level, the contents of the system headers, and any number of other things you can't control easily. Thus, you may get all the warnings out on your canonical build platform(s), but then some poor schmuck tries to build in a more exotic environment and it blows up.
Zack
@Zack, isn't that what -Wno-system-headers is for?
Sam Miller
@Zack: I've never seen warnings triggered by optimizations, (could you cite examples?) and GCC, by default, suppresses warnings from headers marked as system headers (either by `#pragma` or with the `-isystem` switch). None of the things you mention have ever been a problem for me, and, in fact, `-Wall -Wextra -Werror -pedantic` has identified and helped me fix more bugs than I can recount.
greyfade
@greyfade: The most common problem people have is with `-Wuninitialized`, which may or may not be able to avoid false positives on conditional-set-conditional-use patterns that are obvious to a human, depending on the optimization level *and the target architecture*. Which means you may not get warnings on x86 but someone who tries to build for ARM will. Personally I prefer to add "unnecessary" initializations to squelch these, but some people argue _violently_ for not doing that.
Zack
@Zack: GCC *does* provide `-Wno-uninitialized` for cases where that's an issue, but I find it hard to believe that initializing variables is somehow a *bad* thing, even on ARM. (Although I will confess to not having built anything for ARM just yet.)
greyfade
The arguments I've heard for not initializing variables that the compiler gets `-Wuninitialized` false positives on are: it wastes I-cache on dead-but-not-provably-dead store instructions; and if something changes that makes the warning a true positive, we want valgrind to catch it.
Zack