use of memset and optimization

[Tom Yu]

>>>>> "john" == John Hascall <john at iastate.edu> writes:

>> >>>>> "john" == John Hascall <john at iastate.edu> writes:
>> >> Not only does gcc 3.0.3 not optimize out the memset() call, it also
>> >> doesn't inline any of the functions.

john> However, it would be perfectly within its rights to do so,
john> and perhaps some compiler now or in the future does/will.

>> I'm not convinced of that.  Consider that an expression statement is a
>> sequence point.  There is therefore a sequence point between the call
>> to memset() and the call to free().  If it is possible that a signal
>> handler might access the value of the object between those two calls,
>> the standard arguably requires that it be able to see the effects of
>> the memset().

john>    1) volatile requirement (as you mention)
john>    2) the signal handler has no way to access that object anyway
john>       (it's only pointed to by "key" which is local to the function)

It also occurs to me that even if a pointer to "key" escapes, e.g. by
way of the encrypt() function, which is an external reference, a
signal handler can't have defined behavior if it references "key",
since accesses through a pointer after it has been free()ed are
undefined, and there's no guarantee that the signal handler will be
called before free() invalidates the pointer.  I don't think the
standard requires that a signal only be delivered at sequence points.

---Tom