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

[Florian Weimer <fweimer at redhat dot com>]

On 11/21/2017 11:28 PM, Paul Eggert wrote:
> On 11/21/2017 03:00 AM, Florian Weimer wrote:
> > I think the standard assumes that storage for all local variables is 
> > allocated when the function is entered (or when a scope is entered 
> > with which contains a variable of variably modified type).  This is 
> > certainly an odd requirement.
>
> It would be an odd requirement, and I don't see such a requirement in 
> the standard. C11 section 6.8.2 says that a compound statement { ... } 
> is a block, and section 6.2.4 paragraph 6 says that an auto object's 
> lifetime is from block entry until execution of that block ends in any 
> way. In this case, the block's execution ends each time through the 
> loop, so the variables in question do not survive from one loop 
> iteration to the next.

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.

And further on:

“
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.
”

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

This implies to me that if you longjmp into a body of a loop like this:

   while (true)
     {
       int var;
       …  // setjmp and longjmp here
     }

then var has the same address as when the setjmp call occurred, even if 
it happened in a different iteration of the loop.  This makes all kinds 
of optimizations invalid, of course.

Furthermore, with a volatile qualifier

   while (true)
     {
       volatile int var;
       …  // setjmp and longjmp here
     }

even the value is preserved.  This also invalidates numerous 
optimizations which otherwise would be valid (even for volatile objects).

But maybe never really thought about this when writing the standard.

Thanks,
Florian