This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] pthread_cleanup_push macro generates warning when -Wclobbered is set


On 11/22/2017 04:12 AM, Florian Weimer wrote:
I'm deriving this from the wording for longjmp:

“
[…] if the function containing the invocation of the  setjmp macro has terminated execution in the interim, or if the invocation of the setjmp macro was within the scope of an identifier with variably modified type and execution has left that scope in the interim, the behavior is undefined.
I read that it's permitted to jump into a scope which has ceased to exist.

Sure, but this does not mean the program is therefore allowed to access variables past their lifetimes. The rule about variable lifetimes is in addition to the above-quoted rules, and programs must follow all the rules.

Andreas is right: longjmping into a block (from a call whose ancestor is outside the block but in the block's containing function) is like a goto from outside the block to inside the block. Although the variables spring into existence, they are newly allocated and uninitialized (even if volatile) and they don't even have to spring into the same place each time you jump into the block.

The object values become indeterminate, which means that the objects themselves still exist.

Not at all. That section is placing an extra constraint on uses of longjmp: it's saying that certain variables that would ordinarily be initialized, become indeterminate. This does not relieve the program of following all the other rules that it must follow, including the rule on not accessing variables after their lifetimes have expired.

If I take my language-lawyer hat off and think about what the intent is here, it's quite clear. The standard is intending to allow implementations where setjmp does not save callee-save registers into the jmp_buf, so that when longjmp uses the jmp_buf, setjmp can "return" with these callee-save registers trashed and therefore any local variables implemented via callee-save registers can be trashed. That's the main point of all that wording (and of the other seemingly-odd constraints on setjmp). And this underscores the fact that this wording is intended only to impose extra constraints on the use of setjmp/longjmp: in particular, the wording does not promise that local variables will have a longer lifetime than usual merely because setjmp/longjmp is being used.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]