Re: PATCH: don't call cleanup handlers after a regular return from the thread start function

[Rich Felker <dalias@libc.org>]

On Tue, Aug 05, 2014 at 03:41:17PM -0400, Rich Felker wrote:
> > But I have another reason for wanting that, future compatibility with
> > C threads. Programs that are written for C threads will not be aware
> > of such interdictions. Concretely in our case of my C thread v3 patch
> > a user can longjmp from a once-init-handler (written by her or him)
> > through pthread_once (in libc, for musl with pthread_cleanup_push) to
> > the thread start function (again user code) and then return from
> > there. (All of this seems to be allowed by POSIX)
> 
> Such a longjmp is UB unless it's explicitly permitted by the standard
> -- same as longjmp out of qsort. There's no guarantee to a function
> called as a callback from the standard library that the calling
> function does not have internal state which would be left in an
> inconsistent state by longjmp'ing out.

Actually, I can't find the text which supports this, which is odd
since it seems to be common knowledge that you can implement qsort
with algorithms that use allocation if it succeeds. The standard
_does_ contain such text for atexit and at_quick_exit, and I suppose
qsort is covered by the strict interface contract for the comparison
function (the "shall return" requirement cannot be met if the function
calls longjmp). The only other standard library function I'm aware of
which calls back to application code is call_once, so it's not clear
to me whether lack of consideration of longjmp for call_once is an
omission (likely) or an allowance for it to use longjmp (in which the
"exactly once" is probably under-specified, especially since call_once
does not synchronize until "completion of an effective call").

Rich