On Apr 20, 2011, at 7:15 AM, Chris Maynard wrote:
> Do we really need any of these in Wireshark?
To quote ISO/IEC 9899: 1990, "Programming languages -- C":
"7.6.2 Restore calling environment
7.6.2.1 The longjmp function
Synopsis
#include <setjmp.h>
void longjmp(jmp_buf env, int val);
Description
The longjmp function restores the environment saved by the most recent invocation of the setjmp macro in the same invocation of the program, with the corresponding jmp_buf argument. If there has been no such invocation, or if the function containing the invocation of the setjmp macro has terminated execution in the interim, the behavior is undefined.
All accessible objects have values as of the time longjmp was called, ***except that the values of objects of automatic storage duration that are local to the function containing the invocation of the corresponding setjmp macro that do not have volatile-qualified type and have been changed between the setjmp invocation and longjmp call are indeterminate***.
As it bypasses the usual function call and return mechanisms, the longjmp function shall execute correctly in contexts of interrupts, signals and any of their associated functions. However, if the longjmp function is invoked from a nested signal handler (that is, from a function invoked as a result of a signal raised during the handling of another signal), the behavior is undefined."
emphasis mine. GCC, at least, warns about use of variables whose value may be made indeterminate by longjmp, and our exception mechanism uses setjmp/longjmp, and those warnings turn into errors with -Werror....
