Re: how to avoid a memset() optimization

Alex Colvin <alexc@world.std.com> wrote:


> "Francis Wai" <fwai@rsasecurity.com> writes:
>
> ...the case of a memory scrub optimized away by the compiler...
>
> >Various suggestions have been made, such as declaring the variable
> >volatile and having a scrub memory function in a file of its own. I'm
> >wondering if there are better ways such as telling the compiler not to
> >optimize away a function call.
>
> >[Declaring the array volatile is the right way to do it. The reason
> >volatile exists is to tell the compiler not to do otherwise valid
> >optimizations. -John]
>
> I hesitate to contradict the master, but I vote against 'volatile" for
> key[]. ...
>
> You want the compiler to assume a reference to key[] after memset(),
> which is what you're assuming when you worry about someone seeing
> it. Try declaring key[] static or external instead. That warns the
> compiler that you're assuming a lifetime beyond main().


All these suggestions have in common that they try to use language
features in order to achieve a meta-language effect, while relying on
particular compiler implementations (in theory a compiler with global
lifetime analysis could optimize away the code to clear a static key[]
as well).


I think the lesson to be learned here is that compiler writers would do
well to give programmers some control over the compiler mechanics not
covered by the language. In this case, a construct


#pragma eliminate_dead_code=no
      memset(key, 0, sizeof key);
#pragma eliminate_dead_code=restore


would state the programmer's intentions far clearer than any 'volatile'
construct, and also allow other optimizations still be performed on the
key.
[I don't see what the difference is between "volatile" and "don't
eliminate dead code". Volatile exists precisely to tell the compiler
that code that might appear to be dead isn't. -John]

Return to the comp.compilers page.
Search the comp.compilers archives again.