This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] pthread_cleanup_push macro generates warning when -Wclobbered is set
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