"unreachable code". Yea, right!
Steven Schulze
I usually use the maximum Warning Level (level 4), when I build my projects,
to make it easier to find bugs. I usually make sure I get 0 errors and 0
warnings, but now there's a warning I can't get rid of when I do a Release
Build. As far as I can tell, it's an incorrect warning. The warning is:
warning C4702: unreachable code
And when I double-click on it, it jumps to the closing bracket of the
function below. I have traced into the function in debug mode, up to the
last "return registered;" function, and can't figure out what the compiler
is complaining about...
Here's the function...
---------------------------------------------------------------
bool FX_MultLimComp::Register(char* name, char* reg)
{
long result;
HKEY hKey;
int nameLen = strlen(name);
int regLen = strlen(reg);
char subKey[] = "Software\\SOS_Plugin\\FX_MultLimCompGate";
result = RegCreateKeyEx(HKEY_LOCAL_MACHINE,
subKey,
0, NULL, REG_OPTION_NON_VOLATILE,
KEY_ALL_ACCESS, NULL, &hKey, NULL);
if (result != ERROR_SUCCESS) return false;
result = RegSetValueEx(hKey, "User Name", 0, REG_SZ,
(unsigned char*)name, nameLen + 1);
if (result != ERROR_SUCCESS)
{
RegCloseKey(hKey);
return false;
}
result = RegSetValueEx(hKey, "Reg Number", 0, REG_SZ,
(unsigned char*)reg, regLen + 1);
RegCloseKey(hKey);
if (result != ERROR_SUCCESS)
return false;
registered = IsRegistered();
return registered;
} //<<< This is where I get the warning...
---------------------------------------------------------
Can anyone tell me what's going on here?
Steven Schulze
Concord, CA
Bruce Dawson
>
> Hi!
>
> I usually use the maximum Warning Level (level 4), when I build my projects,
> to make it easier to find bugs. I usually make sure I get 0 errors and 0
> warnings, but now there's a warning I can't get rid of when I do a Release
> Build. As far as I can tell, it's an incorrect warning. The warning is:
>
> warning C4702: unreachable code
> Can anyone tell me what's going on here?
>
> Steven Schulze
> Concord, CA
It looks fine. However to investigate this problem you just need to
comment
out return statements until the warning goes away. This will tell you
which
return statement(s) is the problem. The compiler obviously thinks that
one of those return statements will always be taken.
FWIW - you might want to change your result variable to type LONG, since
that is the type that the functions return - it's just faintly possible
that that might help.
--
.Bruce Dawson, Cavedog Entertainment.
Makers of Total Annihilation - http://www.cavedog.com
Steven Schulze
Bruce Dawson wrote in message <35AA7F...@cavedog.com>...
No, the "registered" variable is actually a "bool" that's a member variable
of my class, so it's correctly returning a bool. I think you are thinking
about the "result" variable, which it isn't returning.
I have traced the execution path of the code, and it definitely reaches the
last "return registered;" statement.
I have no idea what's up with the compiler. What's the C++ equivalent of
grabbing the compiler by the throat and shaking it...?
Steven Schulze
Concord, CA
Shaun Ivory
I compiled your fragment, but I couldn't repro the warning on VC5.
Shaun
On Mon, 13 Jul 1998 07:27:44 -0700, "Steven Schulze"
<Capta...@msn.com> wrote:
>Hi!
>
>I usually use the maximum Warning Level (level 4), when I build my projects,
>to make it easier to find bugs. I usually make sure I get 0 errors and 0
>warnings, but now there's a warning I can't get rid of when I do a Release
>Build. As far as I can tell, it's an incorrect warning. The warning is:
>
>warning C4702: unreachable code
>
Richard Norman
Capta...@msn.com says...
>>>
>>> Hi!
>>>
>>> I usually use the maximum Warning Level (level 4), when I build my
>projects,
>>> to make it easier to find bugs. I usually make sure I get 0 errors and 0
>>> warnings, but now there's a warning I can't get rid of when I do a
>Release
>>> Build. As far as I can tell, it's an incorrect warning. The warning is:
>>>
>>> warning C4702: unreachable code
>>> Can anyone tell me what's going on here?
>>>
>>> Steven Schulze
>>> Concord, CA
>>
>>comment
>>out return statements until the warning goes away. This will tell you
>>which
>>return statement(s) is the problem. The compiler obviously thinks that
>>one of those return statements will always be taken.
>>
>>FWIW - you might want to change your result variable to type LONG, since
>>that is the type that the functions return - it's just faintly possible
>>that that might help.
>
>
>No, the "registered" variable is actually a "bool" that's a member variable
>of my class, so it's correctly returning a bool. I think you are thinking
>about the "result" variable, which it isn't returning.
>
>I have traced the execution path of the code, and it definitely reaches the
>last "return registered;" statement.
>
>I have no idea what's up with the compiler. What's the C++ equivalent of
>grabbing the compiler by the throat and shaking it...?
>
But you do have to admit that anything following the return
is, in fact, unreachable! ;-)
Steven Schulze
Richard Norman wrote in message <6ofjip$p8d$1...@denws02.mw.mediaone.net>...
OK, I'll remove the closing bracket :-}
I commented out all the conditional returns earlier in the function, and I
still get the warning.
Steven Schulze
Concord, CA
Steven Schulze
Concord, CA
Rune Huseby
>
> Here's the function...
>
> ---------------------------------------------------------------
>
> bool FX_MultLimComp::Register(char* name, char* reg)
> {
> registered = IsRegistered();
> return registered;
> } //<<< This is where I get the warning...
> Can anyone tell me what's going on here?
Perhaps the compiler knows something about the IsRegistered()-method
we don't know? I.e. if IsRegistered() is define before the
Register()-method
and always throws an exception, the return-statement will never be
reached.
You could also enable debug-info for you release-build, and trace into
your
code. Also look at the assembly-code to see if that gives you a hint.
--
Rune H. H. Huseby
Bruce Dawson
I
meant you might want to change the variable named 'result' to type LONG.
I
suggested this because all of the functions whose results you are
assigning
to 'result' have the return type of LONG, and is usually a good idea to
have the types match exactly, instead of assigning a LONG to a long. I
doubt it matters, but just in case...
I understand that when you execute the code it makes it to the
unreachable
code. However, the fact that the compiler issues the warning means that,
at some level, it thinks it won't make it to the end. In other words,
the compiler thinks that one of the return statements is always
executed.
Therefore, if you want to figure out why the compiler mistakenly
believes
that some of your code is unreachable, you should try commenting out
the various return statements. At some point the warning will go away.
Then you know that the compiler thinks that the return statement that
you just commented out was always returning. Then you can stare at that
statement to try to figure out why.
That is the C++ equivalent of grabbing the compiler by the throat and
shaking it.
Have fun!
Steven Schulze wrote:
>
> Bruce Dawson wrote in message <35AA7F...@cavedog.com>...
> >Steven Schulze wrote:
> >>
> >> Hi!
> >>
> >> I usually use the maximum Warning Level (level 4), when I build my
> projects,
> >> to make it easier to find bugs. I usually make sure I get 0 errors and 0
> >> warnings, but now there's a warning I can't get rid of when I do a
> Release
> >> Build. As far as I can tell, it's an incorrect warning. The warning is:
> >>
> >> warning C4702: unreachable code
> >...
> >> Can anyone tell me what's going on here?
> >>
> >> Steven Schulze
> >> Concord, CA
> >
> >It looks fine. However to investigate this problem you just need to
> >comment
> >out return statements until the warning goes away. This will tell you
> >which
> >return statement(s) is the problem. The compiler obviously thinks that
> >one of those return statements will always be taken.
> >
> >FWIW - you might want to change your result variable to type LONG, since
> >that is the type that the functions return - it's just faintly possible
> >that that might help.
>
> No, the "registered" variable is actually a "bool" that's a member variable
> of my class, so it's correctly returning a bool. I think you are thinking
> about the "result" variable, which it isn't returning.
>
> I have traced the execution path of the code, and it definitely reaches the
> last "return registered;" statement.
>
> I have no idea what's up with the compiler. What's the C++ equivalent of
> grabbing the compiler by the throat and shaking it...?
>
> Steven Schulze
> Concord, CA
Doug Harrison
>Hi!
>
>I usually use the maximum Warning Level (level 4), when I build my projects,
>to make it easier to find bugs. I usually make sure I get 0 errors and 0
>warnings, but now there's a warning I can't get rid of when I do a Release
>Build. As far as I can tell, it's an incorrect warning. The warning is:
>
>warning C4702: unreachable code
>
>And when I double-click on it, it jumps to the closing bracket of the
>function below. I have traced into the function in debug mode, up to the
>last "return registered;" function, and can't figure out what the compiler
>is complaining about...
I don't see any reason for the compiler to complain, either. However,
I did find the following in <afx.h>, among other disabled warnings:
// warnings caused by normal optimizations
#ifndef _DEBUG
#pragma warning(disable: 4701) // local variable *may* be used
without init
#pragma warning(disable: 4702) // unreachable code caused by
optimizations
#pragma warning(disable: 4791) // loss of debugging info in release
version
#endif
It seems even the MFC team thinks C4702 is so often spurious in
release builds that it should be disabled. However, if you can create
a small, stand-alone, reproducible test case that elicits the spurious
warning, I think it would be worth reporting to MSFT.
--
Doug Harrison
dHar...@worldnet.att.net
Steven Schulze
Bruce Dawson wrote in message <35ABA1...@cavedog.com>...
>When I said "you might want to change your result variable to type LONG"
>I
>meant you might want to change the variable named 'result' to type LONG.
>I
>suggested this because all of the functions whose results you are
>assigning
>to 'result' have the return type of LONG, and is usually a good idea to
>have the types match exactly, instead of assigning a LONG to a long. I
>doubt it matters, but just in case...
>
>I understand that when you execute the code it makes it to the
>unreachable
>code. However, the fact that the compiler issues the warning means that,
>at some level, it thinks it won't make it to the end. In other words,
>the compiler thinks that one of the return statements is always
>executed.
>Therefore, if you want to figure out why the compiler mistakenly
>believes
>that some of your code is unreachable, you should try commenting out
>the various return statements. At some point the warning will go away.
>Then you know that the compiler thinks that the return statement that
>you just commented out was always returning. Then you can stare at that
>statement to try to figure out why.
Well, the problem is firstly that it's not any of my code that's shown as
being unreachable, but the CLOSING BRACKET of the function.
Second, I did comment out all the other return statements, and I STILL got
the error message.
It's just one of those things I guess I'll never figure out...
Steven Schulze
Concord, CA
Steven Schulze
Rune Huseby wrote in message <35AB90...@softnet.no>...
>Steven Schulze wrote:
>>
>> Here's the function...
>>
>> ---------------------------------------------------------------
>>
>> bool FX_MultLimComp::Register(char* name, char* reg)
>> {
>[code deleted]
>
>> registered = IsRegistered();
>> return registered;
>> } //<<< This is where I get the warning...
>
>we don't know? I.e. if IsRegistered() is define before the
>Register()-method
>and always throws an exception, the return-statement will never be
>reached.
As far as I know the IsRegistered() function is called and executes fine.
It's a pretty straightforward function.
>You could also enable debug-info for you release-build, and trace into
>your
>code. Also look at the assembly-code to see if that gives you a hint.
I'll try it, but it's just a weird error to get at the closing bracket of a
function, afaic.
Steven Schulze
Concord, CA
Steven Schulze
Chuck Le Mieux wrote in message <6og64q$s...@bgtnsc03.worldnet.att.net>...
>If you have an if() or while() statement in your code that may cause the
>problem your having. Without seeing the entire code theres no telling what
>the cause is.
But I did post the entire offending function. Is it possible that the
warning could show up in one function if the actual error is in another
function? It seems pretty unlikely to me, but I could be wrong.
I guess I'll need to live with the error until I finish this project. Oh
well...
Steven Schulze
Concord, CA
Steven Schulze
Doug Harrison wrote in message <6ogk9t$9...@bgtnsc02.worldnet.att.net>...
I think you are right. This part of my project doesn't use MFC (it's a non
MFC DLL), and therefore the above #pragma's haven't been included. I should
turn off optimizations and see what happens.
I'm kinda surprised though that that warning is disabled in release builds.
I'm sure I've seen it before in MFC release builds (when it was actually a
valid warning).
I made my own "windows.h" -like header file and called it "mywin.h" for all
my non-MFC builds in which I put all my other warning disable #pragmas. I
should add the "disable: 4702" for release builds.
I guess it makes sense. If you don't get the warning with debug builds,
your code should be ok.
I think you gave me the answer I was looking for - thanks!
Steven Schulze
Concord, CA
Martin Cooper
<OOBk8V$r9GA...@uppssnewspub05.moswest.msn.net>...
> I guess it makes sense. If you don't get the warning with debug builds,
> your code should be ok.
If only it were so!
One example of why that's a bad assumption: C4700 (uninitialized variable
access) is only generated for release builds - you'll never see it in debug
builds, but that doesn't mean your code is OK. Worse, it's only a warning,
which you might ignore. (We use "#pragma warning" to force this to be an
error.)
--
Martin Cooper
Worldtalk Corporation
Brandon Ehle
logic. I have encountered it before on several occasions which all compiled
without any errors at all under BC5.02
Steven Schulze
Richard Norman wrote in message <6ofjip$p8d$1...@denws02.mw.mediaone.net>...
>In article <eKxd$ftr9G...@uppssnewspub05.moswest.msn.net>,
>Capta...@msn.com says...
>>
>>
>>>Steven Schulze wrote:
>>>>
>>>> Hi!
>>>>
>>>> I usually use the maximum Warning Level (level 4), when I build my
>>projects,
>>>> to make it easier to find bugs. I usually make sure I get 0 errors and
0
>>>> warnings, but now there's a warning I can't get rid of when I do a
>>Release
>>>> Build. As far as I can tell, it's an incorrect warning. The warning
is:
>>>>
>>>> warning C4702: unreachable code
>>>> Can anyone tell me what's going on here?
>>>>
>>>> Concord, CA
>>>
>>>It looks fine. However to investigate this problem you just need to
>>>comment
>>>out return statements until the warning goes away. This will tell you
>>>which
>>>return statement(s) is the problem. The compiler obviously thinks that
>>>one of those return statements will always be taken.
>>>
>>>FWIW - you might want to change your result variable to type LONG, since
>>>that is the type that the functions return - it's just faintly possible
>>>that that might help.
>>
>>
>>No, the "registered" variable is actually a "bool" that's a member
variable
>>of my class, so it's correctly returning a bool. I think you are thinking
>>about the "result" variable, which it isn't returning.
>>
>>I have traced the execution path of the code, and it definitely reaches
the
>>last "return registered;" statement.
>>
>>I have no idea what's up with the compiler. What's the C++ equivalent of
>>grabbing the compiler by the throat and shaking it...?
>>
>
>is, in fact, unreachable! ;-)
Yes, I realize this, but do we need the compiler to tell us that each and
every closing bracket at the end of each and every function is unreachable?
Steven Schulze
Concord, CA
Steven Schulze
Martin Cooper wrote in message <01bdb1e9$f00556e0$095bb1cc@twine>...
I'm specifically talking about warning "C4702: unreachable code". If all
code in your debug build is reachable, it should be so in the release build
too. That's my point, and that's why it's ok to turn it off in the release
build.
Steven Schulze
Concord, CA
Agent
>you just commented out was always returning. Then you can stare at that
>statement to try to figure out why.
>
>shaking it.
RTOFL!
Henri Hein
Steven Schulze <Capta...@msn.com> wrote in article
<OmhnKx5...@uppssnewspub05.moswest.msn.net>...
>
> I'm specifically talking about warning "C4702: unreachable code". If all
> code in your debug build is reachable, it should be so in the release
build
> too. That's my point, and that's why it's ok to turn it off in the
release
> build.
I totally disagree with this. Identifying unreachable code is a classic
and one of the more challenging aspects of a compilers optimizer.
Since the debug build doesn't optimize, it wouldn't detect those
areas. Also, the optimizer moves code around quite a bit - to be
sure that there are no unreachable sections, you would need to
look at the generated assembly code.
- Henri
--
Henri Hein
Sr. Software Engineer
h...@thevisionfactory.com
http://www.thevisionfactory.com
Doug Harrison
<coo...@nospam.worldtalk.com> wrote:
>One example of why that's a bad assumption: C4700 (uninitialized variable
>access) is only generated for release builds - you'll never see it in debug
>builds, but that doesn't mean your code is OK. Worse, it's only a warning,
>which you might ignore. (We use "#pragma warning" to force this to be an
>error.)
This is improved in VC6; C4700 is issued even in debug builds (-Od).
There are also some nice, new warnings, involving code such as:
if (x);
{
y();
}
--
Doug Harrison
dHar...@worldnet.att.net
Doug Harrison
<Capta...@msn.com> wrote:
>I'm specifically talking about warning "C4702: unreachable code". If all
>code in your debug build is reachable, it should be so in the release build
>too. That's my point, and that's why it's ok to turn it off in the release
>build.
Problem is, VC++ prior to VC6 apparently doesn't do the flow analysis
necessary to detect such problems, unless you compile with
optimizations. Consider:
void fun(int& x)
{
return;
++x;
}
In VC5, I don't get the C4702 for the above unless I compile with
(say) -O1. VC6, however, is supposed to detect this problem if you
compile with -Od, which is included in debug builds.
--
Doug Harrison
dHar...@worldnet.att.net
Steven Schulze
Henri Hein wrote in message <01bdb430$71016a70$c80a8bcc@demowork>...
>
>
>Steven Schulze <Capta...@msn.com> wrote in article
><OmhnKx5...@uppssnewspub05.moswest.msn.net>...
>>
>> code in your debug build is reachable, it should be so in the release
>build
>> too. That's my point, and that's why it's ok to turn it off in the
>release
>> build.
>
>and one of the more challenging aspects of a compilers optimizer.
>Since the debug build doesn't optimize, it wouldn't detect those
>areas. Also, the optimizer moves code around quite a bit - to be
>sure that there are no unreachable sections, you would need to
>look at the generated assembly code.
I mean as far as your logic flow of your own C++ lines of code goes, a
purely high-level programming point, it's fine. What the compiler does to
your code to optimize it for the release build doesn't particularly interest
me. The point is that I then know I haven't made some dumb logic flow
mistake, like putting a return in both if/else blocks, and another return
after the else block.
That's what I meant...
Steven Schulze
Concord, CA