CODEWITHSUNDEEP
c++visual-c++
NFRCR
NFRCR

Reputation: 5570

Is the compiler allowed to do such an optimization?

Compiler: VC++2013 Mode: Release

Story: I learned about IAT hooking. I decided to practise on ExitProcess(). I got crashes as soon as the replacement function returned. Why? Because somehow the compiler decided to think that what follows ExitProcess() will never be executed so that code was not generated. For example when I put ExitProcess() inside an if statement everything went fine. So how is this a valid optimization? ExitProcess() is inside a DLL, so the compiler couldn't even do any link-time optimizations if it wanted to. It just magically assumes that ExitProcess() will never return.

I think the compiler should not do such things.

Upvotes: 2

Views: 104

Answers (2)

user395760
user395760

Reputation:

The declaration of ExistProcess in the relevant header is presumably annotated with __declspec(noreturn). Since this is a language extension, not a standard language construct, it's within the discretion of the compiler writers (as opposed to the standard committee) whether such optimizations are allowed.

Upvotes: 3

Puppy
Puppy

Reputation: 146910

ExitProcess is defined by the documentation to never return. If you wrote a replacement function that does return, then that's you breaking the promise the documentation made, and any breakage as a result is your problem.

C++11 Standardised the notion of such functions and has a notation for them. VS does not implement this yet I believe, but there's nothing preventing them from implementing it for specific functions.

Why shouldn't the compiler assume that ExitProcess() does not return? It's pretty clearly defined to exit the process.

Upvotes: 5

Related Questions