use of memset and optimization
tlyu at MIT.EDU
Fri Nov 8 12:25:01 EST 2002
>>>>> "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.
More information about the krbdev