On Feb 20, 2008 8:42 AM, David Brown <[EMAIL PROTECTED]> wrote:
> On Wed, Feb 20, 2008 at 12:41:37AM -0800, Bob La Quey wrote:
>
> >That is _not_ how I read:
> >"A call to setjmp() shall save the calling environment in its env
> >argument for later use by longjmp()."
> >
> >http://www.opengroup.org/onlinepubs/000095399/functions/setjmp.html
> >
> >I think that we all understand the issues though.
> >The question is, "What does setump() do."
>
> Setjmp moves a few registers into the jmpbuf() structure.  That's it.  Read
> the page on longjmp() which is explains in more detail, specifically:
>
>    "If there is no such invocation, or if the function containing the
>    invocation of setjmp() has terminated execution in the interim, or if the
>    invocation of setjmp() was within the scope of an identifier with
>    variably modified type and execution has left that scope in the interim,
>    the behavior is undefined."
>
> If the function has terminated execution in the interim.  Posix doesn't
> want to define behavior based on a particular execution model.  They also
> defer to the ANSI C spec for the calls.  You are only allowed to longjmp
> out of a calling context, not back into it.
>
> It's actually much worse than even that.  setjmp()/longjmp() are only
> required to preserve static variables across the call.  Local variables in
> effect in the caller are not required to be preserved.  This means that
> setjmp isn't even required to save the registers other than the stack
> pointer.  Some implementations do, some don't.
>
> The setjmp() in Linux x86 glibc, specifically saves %ebx, %esi, %edi, %ecx,
> and %ebp.  That's it.
>
> David

OK. Got it. IMHO the sentence I quoted about saving the
calling environment is a bit misleading.

Your point about POSIX not specifying an execution model
is well taken. So with C, right? i.e. no virtual machine
and the language can and is compiled to many different
execution models. This explains a lot of things, good
and bad, about C.

One of the facts about FORTH, again good and bad, but
definitely different from C is that the execution model
and the language are almost always intimately related.
You need to understand both to use FORTH well and to
read FORTH code.

BobLQ


BobLQ

-- 
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg

Reply via email to