相关文章推荐
高兴的板栗  ·  node.js - How to ...·  2 年前    · 
开朗的熊猫  ·  c# - ...·  3 年前    · 
Collectives™ on Stack Overflow

Find centralized, trusted content and collaborate around the technologies you use most.

Learn more about Collectives

Teams

Q&A for work

Connect and share knowledge within a single location that is structured and easy to search.

Learn more about Teams

I'm reviewing a C++ MFC project. At the beginning of some of the files there is this line:

#pragma optimize("", off)

I get that this turns optimization off for all following functions. But what would the motivation typically be for doing so?

Maybe the programmer liked a reliable stack trace when the program bombs. Maybe he tried to work around a code optimizer bug. Maybe he didn't know what he was doing and applied cargo cult. – Hans Passant Mar 13, 2015 at 13:34 Another reason would be to obfuscate the resulted binary. To make reverse engineering harder (of course if the source code is open this is pointless). – freakish Jan 8, 2018 at 9:55 @freakish it seems that Themida is relaying on this when trying to obfuscate a return statement within a VM see screenshot from the documentation – itsho May 21, 2019 at 10:23

I've seen production code which is correct but so complicated that it confuses the optimiser into producing incorrect output. This could be the reason to turn optimisations off.

However, I'd consider it much more likely that the code is simply buggy, having Undefined Behaviour. The optimiser exposes that and leads to incorrect runtime behaviour or crashes. Without optimisations, the code happens to "work." And rather than find and remove the underlying problem, someone "fixed" it by disabling optimisations and leaving it at that.

Of course, this is about as fragile and workarounds can get. New hardware, new OS patch, new compiler patch, any of these can break such a "fix."

Even if the pragma is there for the first reason, it should be heavily documented.

Thanks. No documentation surrounding those lines. I guess I will make an attempt to remove them and keep an eye out for side effects. – Stokke Mar 13, 2015 at 13:45

Another alternative reason for these to be in a code base... Its an accident.

This is a very handy tool for turning off the optimizer on a specific file whilst debugging - as Ray mentioned above.

If changelists are not reviewed carefully before committing, it is very easy for these lines to make their way into codebases, simply because they were 'accidentally' still there when other changes were committed.

I know this is an old topic, but I would add that there is another reason to use this directive - though not relevant for most application developers.

When writing device drivers or other low-level code, the optimizer sometimes produces output that does not interact with the hardware correctly.

For example code that needs to read a memory-mapped register (but not use the value read) to clear an interrupt might be optimized out by the compiler, producing assembly code that does not work.

This might also illustrate why (as Angew notes) use of this directive should be clearly documented.

A similar case is when you want to perform an exact set of operations for cryptographic purposes. A side channel attack can measure the time/power consumption that various branches take to execute, optimizations may not be identical on two similar looking code paths thus leaking information en.wikipedia.org/wiki/Timing_attack – Lockyer Jul 11, 2018 at 12:31 Or to prevent busy wait loops from being optimized out (You want the side effect of time to be retained). Also check out this page for general gotchas when attempting to clear a block of memory: wiki.sei.cmu.edu/confluence/display/c/… – Gregory Kuhn Feb 11, 2021 at 15:20

Thanks for contributing an answer to Stack Overflow!

  • Please be sure to answer the question. Provide details and share your research!

But avoid

  • Asking for help, clarification, or responding to other answers.
  • Making statements based on opinion; back them up with references or personal experience.

To learn more, see our tips on writing great answers.