On 09/05/16 22:45, Michael Matz wrote:
> On Mon, 9 May 2016, Rich Felker wrote:
>
>>> Done. I never understood why they left in the hugely unuseful
>>> {sig,}{set,long}jmp() but removed the actually useful *context()
>>> (amended somehow like above).
>>
>> Because those are actually part of the C language
>
> Sure. Same QoI bug in my book. (And I'm not motivated enough to find out
> if the various C standards weren't just following POSIX whe setjmp was
> included, or really the other way around).
>
>> (the non-sig versions, but the sig versions are needed to work around
>> broken unices that made the non-sig versions save/restore signal mask
>> and thus too slow to ever use). They're also much more useful for
>> actually reasonable code (non-local exit across functions that were
>> badly designed with no error paths)
>
> Trivially obtainable with getcontext/setcontext as well.
>
>> as opposed to just nasty hacks that
>> are mostly/entirely UB anyway (coroutines, etc.).
>
> Well, we differ in the definition of reasonable :) And I certainly don't
> see any material difference in undefined behaviour between both classes of
> functions. Both are "special" regarding compilers (e.g. returning
> multiple times) and usage. But as the *jmp() functions can be implemented
> with *context(), but not the other way around, it automatically follows
no, no, no,
don't try to present getcontext as equal to setjmp,
getcontext is broken while setjmp is just ugly.
setjmp is defined so that the compiler can treat it
specially and the caller has to make sure certain
objects are volatile, cannot appear in arbitrary
places (e.g. in the declaration of a vla), longjmp
must be in same thread etc.
all those requirements that make setjmp implementible
at all were missing from the getcontext specs, so you
can call it through a function pointer and access
non-volatile modified local state after the second
return, etc. (the compiler treating "getcontext"
specially is a hack, not justified by any standard.)
i think both gccgo and qemu can setcontext into another
thread, so when getcontext returns all tls object
addresses are wrong.. the semantics of this case was
not properly defined anywhere (and there are
implementation internal objects with thread local
storage duration like fenv so this matters even if
the caller does not use tls). this is unlikely to
work correctly with whatever safestack implementation.
setcontext were originally specified to be able to
use the ucontext from async signal handlers.. this
turned out to be problematic for several reasons
(kernel saved ucontext is different from user space
ucontext and sigaltstack needs special treatment).
if setcontext finishes executing the last linked
context in the main thread it was not clearly
specified what cleanups will be performed.
there is just a never ending list of issues with
these apis, so unless there is an actual proposal
how to tighten their specification, any caller of
the context apis rely on undefined semantics.
> (to me!) that the latter are more useful, if for nothing else than basic
> building blocks. (there are coroutine libs that try to emulate a real
> makecontext with setjmp/longjmp on incapable architectures. As this is
> impossible for all corner cases they are broken and generally awful on
> them :) )
>
>
> Ciao,
> Michael.
>
