Unreachable code in string header (basic_string.h). Why? How can I fix it?

[Germinx]

Hello community.

I'm using g++ with the -Wunreachable-code and the -Wfatal-errors -Werror options enabled to compile a piece of code, but... when I use the standard string header I get an unreachable code error and I don't know why.

Here is the code:

#include <string>
#include <iostream>
using namespace std;

int main () {

	string mystring;

	cout << "Type something and press ENTER: " << endl;      

	cin >> mystring;
	
	cout << mystring << endl;

	return 0;

}

And here is the output I get:

cc1plus: warnings being treated as errors
/usr/include/c++/4.4/bits/basic_string.h: In constructor ‘std::basic_string<_CharT, _Traits, _Alloc>::basic_string() [with _CharT = char, _Traits = std::char_traits<char>, _Alloc = std::allocator<char>]’:   
/usr/include/c++/4.4/bits/basic_string.h:2147: error: will never be executed
compilation terminated due to -Wfatal-errors.

Is my code wrong? Is a bug in the header file? Is a false positive?

Why there is a statement that will never be executed?

I have searched the web but I haven't found an answer easily. If someone could help me I would be very pleased.

OS:
Debian GNU/Linux 6.0.4 (squeeze)

Installed packages:
g++-4.4 (4.4.5-8)
libstdc++6-4.4-dev (4.4.5-8)

Thanks in advance and escuse me by my poor English.

Germinx.

[kbw]

The optimiser may drop some of your code, in which case it'll tell you wtih -Wunreachable-code. But if you then tell the compiler to treat warnings as errors with -Wfatal-errors, then it'll treat the warning as an error and stop.
http://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html

[Germinx]

-Wunreachable-code:

"Warn if the compiler detects that code will never be executed.

This option is intended to warn when the compiler detects that at least a whole line of source code will never be executed, because some condition is never satisfied or because it is after a procedure that never returns.

It is possible for this option to produce a warning even though there are circumstances under which part of the affected line can be executed, so care should be taken when removing apparently-unreachable code.

For instance, when a function is inlined, a warning may mean that the line is unreachable in only one inlined copy of the function.

This option is not made part of -Wall because in a debugging version of a program there is often substantial code which checks correct functioning of the program and is, hopefully, unreachable because the program does work. Another common use of unreachable code is to provide behavior which is selectable at compile-time."

First of all thanks for your gentile answer.

I knew that -Werror (I made a mistake in my first post and I wrote -Wfatal-errors when it should say -Werror) converts warnings into errors (stopping the compiler). That is intentional to force me to fix any warning before continue coding.

What I didn't know was that the dropping was induced by the optimization process. (Thanks a lot for the clarification.)

But I would be interested in knowing how can avoid that dropping not in knowing how can avoid that warning.

If I would like to turn off that warning I could use:

#pragma GCC diagnostic ignored "-Wunreachable-code"

But I don't want to do that. I don't want to hide the warning. I would like to safely fix the problem in:

/usr/include/c++/4.4/bits/basic_string.h:2147

I'm sorry but I didn't explain that well the first time.

Best regards Germinx.

[kbw]

Typically you'll get that warning with an optimised compile. It's not confined to GCC either, other C/C++ compilers emit that warning under similar circumstances.

If you got this warning with a debug build, then you really should take a look at the code as there will almost certainly be an issue.

[Germinx]

How could I make that debug build?

With the -g -O0 options? or are you talking about another thing?

With that options I still have the warnings.

[kbw]

-g should suffice.

[Germinx]

Warnings are still there with a debug build.

Looking at the sources makes me think that it could be caused by code that is selectable at compile-time. Though I'm not really sure and I don't know how to safely remove unused parts.

Conclusion: My code is fine. It isn't a bug in the header. It isn't a false positive.

Thanks a lot for your interest and your time.

Germinx.