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....
___________________________________________________________________________
Sent via: Wireshark-dev mailing list <[email protected]>
Archives: http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:[email protected]?subject=unsubscribe
