More on in-memory zeroisation

[Thierry Moreau]

Leichter, Jerry wrote:

> If the function is defined as I suggested - as a static or inline - you
> can, indeed, takes its address.  (In the case of an inline, this forces
> the compiler to materialize a copy somewhere that it might not otherwise
> have produced, but not to actually *use* that copy, except when you take
> the address.)  You are allowed to invoke the function using the address
> you just took.  However, what in that tells you that the compiler -
> knowing exactly what code will be invoked - can't elide the call?

Case of static function definition: the standard says that standard 
library headers *declare* functions, not *define* them.

Case of inline: I don't know if inline definition falls in the standard 
definition of declaration.

Also, the standard refers to these identifiers as external linkage. This 
language *might* not creare a mandatory provision if there was a 
compelling reason to have static or inline implementation, but I doubt 
the very infrequent use of (memset)(?,0,?) instead of memset(?,0,?) is a 
significant optimization opportunity. The compiler writer risks a 
non-compliance assessment in making such strectched reading of the 
standard in the present instance, for no gain in any benchmark or 
production software speed measurement.

Obviously, a pointer to an external linkage scope function must adhere 
to the definition of pointer equality (==) operator.

Maybe a purposedly stretched reading of the standard might let you make 
your point. I don't want to argue too theoretically. Peter and I just 
want to clear memory!

Kind regards,


-- 

- Thierry Moreau

CONNOTECH Experts-conseils inc.
9130 Place de Montgolfier
Montreal, Qc
Canada   H2M 2A1

Tel.: (514)385-5691
Fax:  (514)385-5900

web site: http://www.connotech.com
e-mail: thierry.moreau at connotech.com

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