Re: volatile

[Guy Harris <guy () alum mit edu>]

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 <wireshark-dev () wireshark org>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe