Did you *really* zeroize that key?

[Krister Walfridsson]

On Thu, 7 Nov 2002, Don Davis wrote:

>    * standards-compliant compilers normally distinguish
>      between "conformant" source programs and "noncon-
>      formant" source programs.  for example, a noncon-
>      formant program might be one that uses a deprecated
>      feature.  with nonconformant source programs, the
>      compiler can perfectly legitimately bend various
>      compilation rules, especially so as to get better
>      optimization results.   the idea is that the spec's
>      strict rules and semantics only make sense for
>      conformant programs.

My experience is that in practice the opposite is true. Nonconformant
source code usually contains constructs that will give unexpected results
when optimized using newer ideas in the C language (such as aliasing),
so the compiler will in general be much more conservative when doing
optimizations on such code.


Consider for example the code (we assume sizeof(int) == sizeof(long))

   {
      int a = 23;
      long *p;

      p = &a;

      *p += 5;

      if (a > 23)
      {
          foo();
      }
   }

If we opimized this as if it was confomant code, then we would determine
that p cannot alias with a (since they has different type), so the if-
statement will always evaluate to "false", and may thus be removed, i.e.
the code snippet collapses to

   {
      int a = 23;
      long *p;

      ptr = &a;

      *p += 5;
   }

This kind of optimization is a really big win in some kinds of real world
programs, but cannot be done on nonconformant code.


Btw. one of the more important reasons that gcc does never optimize away
volatile is that every time this optimization is mentioned, there is
always a lot of flamage from embedded programmers that fear what will
happen when their timing loops

   volatile int i;
   for (i=0; i < 100000; i++)
      ;

gets optimized...

   /Krister


---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com