up vote 1 down vote favorite
1

I am using Delphi 7 IDE. Does Delphi compiler optimize codes, just like what the C++ compiler is doing in this following link?

http://msdn.microsoft.com/en-us/library/aa366877(VS.85).aspx

WCHAR szPassword[MAX_PATH];
// Retrieve the password
if (GetPasswordFromUser(szPassword, MAX_PATH))    
   UsePassword(szPassword);
// Clear the password from memory
SecureZeroMemory(szPassword, sizeof(szPassword));

If ZeroMemory were called in this example instead of SecureZeroMemory, the compiler could optimize the call because the szPassword buffer is not read from before it goes out of scope. The password would remain on the application stack where it could be captured in a crash dump or probed by a malicious application.

share|improve this question
81% accept rate
feedback

4 Answers

up vote 10 down vote accepted

Yes, of course Delphi performs optimizations. However, it does not perform the optimization that the SecureZeroMemory function is meant to circumvent. There is no need to use that function in Delphi; just use plain old ZeroMemory, or even FillChar. They're not macros, and they don't do anything that Delphi recognizes as being unused assignment statements that could get optimized out.

share|improve this answer
feedback
up vote 2 down vote

Delphi performs code optimization by default, you can disable it in Project > Options > Compiler.

The Delphi help provide a few tips of what type of optimizations are used:

The $O directive controls code optimization. In the {$O+} state, the compiler performs a number of code optimizations, such as placing variables in CPU registers, eliminating common subexpressions, and generating induction variables.

It also states that "the compiler performs no "unsafe" optimizations", but in the sense that they won't alter the execution path, not from a security point of view.

share|improve this answer
feedback
up vote 0 down vote

I don't believe the compiler will ever eliminate apparently dead code like this. I have never had trouble setting breakpoints on code that could have been eliminated as redundant.

share|improve this answer
6  
Actually, I have. Methods not being called at all, won't be included in your .EXE, and you breakpoints you put there won't show up as reacahble. – Jeroen Wiert Pluimers Nov 3 '10 at 4:10
That situation is different, @Jeroen. Loren is talking about code that is reachable, but which would have no effect if it executed. Sufficiently smart compilers can recognize that the code would have no effect and omit it. A good example is the one in the question, where the password array is never used after being cleared. If the compiler knows to treat ZeroMemory as an assignment statement, and it's set to optimize out assignments that are never used later, then calls to ZeroMemory might be eliminated. SecureZeroMemory is simply a new function that compilers don't know they can omit. – Rob Kennedy Nov 3 '10 at 13:20
feedback
up vote 0 down vote

For some scenarios, the compiler can detect if the code is unreachable and eliminate the code.

For instance, the compiler correctly eliminates the "unreachable" portion of the code below.
It will not generate code for that line so:

  1. So there are no blue bullets indicating there is code
  2. Breakpoints put on that line will be marked visually as 'not reachable'

Just tested in Delphi XE, but older Delphi versions have similar behaviour.

program Project1;

{$APPTYPE CONSOLE}

uses
  SysUtils;

procedure Test;
begin
  if (True = False) then
    Writeln('Unreachable')
  else
    Writeln('Reachable');
end;

begin
  try
    Test();
  except
    on E: Exception do
      Writeln(E.ClassName, ': ', E.Message);
  end;
end.

It takes quite some while to learn when (or when not) the optimizer on code level and liker level kicks in.

For instance: When you have optimizations turned on, the compiler will also eliminate variables as soon as they are not used.
Sometimes, it even eliminates global symbols. Danny Thorpe (former Delphi Compiler engineer and Chief Scientist) once wrote a magic method Touch that prevents this.
Just call this Touch method at the end of your method to fool the optimizer during debugging:

procedure Touch(var arg);
begin
end;

--jeroen

share|improve this answer
feedback

Your Answer

 
or
required, but never shown
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.