Jump to content
  • Advertisement
Sign in to follow this  

vc++ compiler bug or fixable error?

This topic is 3681 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I have compiled the following code in Visual C++ Express 9.0.21022.8. I use Warning Level 4 and I have C++ exceptions enabled (/EHsc)
void ThrowingFunction()
  {
  throw SomeException();
  }

int OtherFunction()
  {
  ThrowingFunction();
  return 0; //C4702
  }

In release the code generates warning "C4702 unreachable code" for the return statement. If I remove that line, I get a warning in debug ("C4715 not all control paths return a value"). Since I'm treating warnings as errors, this is a problem :) I can see why the 'unreachable code' warning is triggered: if the compiler inlines ThrowingFunction the result would be
int OtherFunction()
  {
  throw SomeException();
  return 0; //C4702
  }

But I don't think the result of optimisations should be my problem... Or am I missing something here? The above example is obviously a simplification. Here is my actual code:
void ThrowFailedAPICallException(const TString& i_message_base)
  {
  TString error_message = i_message_base + L": " + GetLastErrorMessage();
  throw FailedAPICallException(error_message);
  }

AutoHandle OpenProcessToken()
  {
  HANDLE h_token;

  if (OpenProcessToken(GetCurrentProcess(), MAXIMUM_ALLOWED, &h_token) == TRUE)
    return AutoHandle(h_token);
    
  ThrowFailedAPICallException(L"Failed to open process token");

  return AutoHandle();
  }

Share this post


Link to post
Share on other sites
Advertisement
Declare your throwing function as __declspec(noreturn), and that should tell the compiler not to expect any code after the function call to be executed.

Share this post


Link to post
Share on other sites
Yup, that fixes the error. Thanks! I've googled the noreturn thingy, and it seems that even if it is not according to the c++ standard, MS will not likely fix it: Visual C++ Team Blog: Bug Submission Guidelines. In the last paragraph of that post, it says
Quote:

If any of the following applies, we will not consider a fix for the bug:
· A reasonable workaround exists

I guess using __declspec(noreturn) is a reasonable workaround.
Still don't like it though...

Share this post


Link to post
Share on other sites
I just thought of a workaround:

AutoHandle OpenProcessToken()
{
HANDLE h_token;

if (OpenProcessToken(GetCurrentProcess(), MAXIMUM_ALLOWED, &h_token) == FALSE)
ThrowFailedAPICallException(L"Failed to open process token");

return AutoHandle(h_token);
}


This is even better: no declspec needed, and less lines of code [grin]

Share this post


Link to post
Share on other sites
If I infer correctly, are you trying for open-source? You could do something like this to keep your portability:


#ifdef _MSC_VER
# define SPEC_NORETURN __declspec( noreturn )
#else
# define SPEC_NORETURN
#endif

void SPEC_NORETURN ThrowingFunction()
{
/* ... */
}




Share this post


Link to post
Share on other sites
Quote:
Original post by _fastcall
If I infer correctly, are you trying for open-source?

No, not at all. I was writing a small tool for my own use. I simply prefer to not use compiler specific constructs in my code.
But thanks anyway for the suggestion!

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!