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

[Paul Eggert]

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.