Leichter, Jerry wrote:

| > There was a discussion on this list a year or two back about
| > problems in using memset() to zeroise in-memory data, specifically
| > the fact that optimising compilers would remove a memset() on
| > (apparently) dead data in the belief that it wasn't serving any
| > purpose.
| | Then, s/memset(?,0,?)/(memset)(?,0,?)/ to get rid of compiler
| in-lining.
| | Ref: ANSI X3.159-1989, section 4.1.6 (Use of C standard library
| functions)
I don't have te C89 spec handy (just the C99 spec, which is laid
out differently), but from what I recall, this construct guarantees
nothing of the sort.

Most standard library functions can be implemented as macros.  Using the
construct (f)(args) guarantees that you get the actual function f,
rather than the macro f.

Indeed, the actual function, memcpy in the present instance.

memcpy, the actual function, is aware of the execution environment, because it is part of the run-time library. The compiler is not as deeply aware of the execution environment.

The source code construct (f)(args) is provided by the standard to allow the program to explicitly rely on the actual library function.

At least this is my understanding of compiler optimization techniques as subordinate to standard definition of the C language. I too often turned off optimization due to (suspected) optimized-in crash, I would like to rely on the (f)(args) to locally turn off optimization.

However, that doesn't say anything about
whether f is actually invoked at run time.  That comes under the "acts
as if" rule:  If the compiler can prove that the state of the C
(notional) virtual machine is the same whether f is actually invoked or
not, it can elide the call.  Nothing says that memset() can't actually
be defined in the appropriate header, as a static (or, in C99, inline)
function.

The standard actually says "... it is permitted to take the address of a library function even if it is defined as a macro ...". The standard works for me as a source code author who needs an execution-aware memcpy function from time to time. Overworked GCC contributors should work to comply to the standard, not to address Peter, Thierry, and whoever's wildests dreams.

Then the compiler can look at the implementation and "prove"
that a memset() to a dead variable can be elided....

It can't prove much in the case of (memset)()


Regards,

--

- Thierry Moreau

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Reply via email to