Re: Are destructors ever optimized away?
On May 13, 9:46 am, "robertwess...@yahoo.com"
<robertwess...@yahoo.com> wrote:
On May 13, 2:08 am, joshuamaur...@gmail.com wrote:
On May 12, 11:25 pm, "robertwess...@yahoo.com"
[...]
I more-or-less agree, but there is no defined precedence
between the as-if rule and the definition of volatile, and
that the as-if rule is commonly interpreted to apply to
everything, I think it's not unreasonable to assume that the
required effects of volatile can be omitted if the compiler
can prove that no other part of the system *can* cause it to
be "modified in ways unknown to the implementation, or have
other unknown side effect."
The as-if rule applies if and only if the change does not affect
"observable behavior". Accesses to volatile objects are
observable behavior, exactly in the same way a read or write to
a file is observable behavior. A compiler cannot "optimize" it
out any more than it can optimize out reads and writes to files.
The problem in most cases is that "what constitutes and access"
is implementation defined. Which normally means that the
implementation is required to document it (but I've never seen
such documentation). From actual examination of generated code,
I've concluded that the definition used by g++, Sun CC and VC++
(at least in the versions I have access to) is simply issuing
the load or store instruction is considered the access. On most
modern machines, this doesn't mean that the value will actually
end up in physical memory---it does mean, however, that within
the executing thread, the old values will no longer be
available.
[...]
I'd suggest the OP more clearly explain what he's trying to
accomplish with this destructor, and why he's so worried
about the compiler optimizing it away in the case when the
object is about to die. Chances are, I'd guess he's trying
to do something non-standard, like using volatile as a
threading primitive (which is totally broken on a general
platform).
What he's trying to do is securely clear a crucial part of the
RC4 encryption function's state after being done using it.
If so, then overwriting the memory with 0's isn't going to
change much.
So another program could not come along and look into memory
and perhaps be able to break the encrypted message by reading
that state. A similar problem exists with programs that have
to store passwords in memory while processing them. Using a
simple memset() to clear that very often does not work because
a memset() of an array that's not further used can often be
optimized away. A program like a debugger, or some injected
code that might look at the stack area at an (in)opportune
time might be able to pick that up.
The real problem is that an older image of the memory exists in
virtual memory, on disk. And depending on the way virtual
memory is managed, the memory he's overwritten may never be
paged out (rewritten to disk), or it may be paged to a different
sector, leaving the earlier data on disk. If a program is
concerned about such issues, the first thing it has to do is to
lock the page with the buffer in RAM, so that it will never be
paged out. Having done that, memsetting the memory (perhaps by
calling a function in a different translation unit) is probably
sufficient, especially if you turn off optimization on the
translation unit(s) which does it.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34