NetNews Usenet Archive 1992 #20/NN_1992_20.iso/spool/comp/os/mswindo/programm/win32/908

Internet Message Format | 1992-09-10 | 1.7 KB

From: [e-mail] (Edward McClanahan)
Date: Thu, 10 Sep 1992 00:02:42 GMT
Subject: Re: setjmp/longjmp
Message-ID: <[e-mail]>
Organization: Hewlett Packard, Cupertino
Path: sparky!uunet!wupost!sdd.hp.com!scd.hp.com!hplextra!hpcc05!hpcuhb!hpda!hpcss01!hpcuhe!edwardm
Newsgroups: comp.os.ms-windows.programmer.win32
References: <[e-mail]>
Lines: 25

[e-mail] (Ravi Pandya) writes:

> The July NT x86 toolset does not include setjmp/longjmp - the header
> file is ifdef'ed out, and it is not in the library. It is a fairly
> straightforward piece of assembly code to write, but before I do it,
> I'd like to know if there are any subtle reasons why the obvious
> approach won't work. Does NT do any odd messing around with stacks,
> privilege levels, etc that would make it hard? I have a suspicion that
> something like this is the reason it is not in the library.

> Unfortunately, our port from UNIX to NT cannot proceed without it, or
> some facsimile, since it is used in our own exception handling
> package, which is used everywhere. We could move it over to the MS
> exception handler, except that it doesn't seem to be available nor
> documented yet... Any suggestions?

I suppose that one reason NT may have commented out setjmp/longjmp is
to avoid dealing with longjumps out of user signal handlers.  This sounds
like your primary use of the function.  I imagine that some NT-internal
process/thread/signal management code may get confused if your signal
handlers don't return...  This is not an unsolvable problem, but uSoft
probably has some work to do in the Deliver User Signals code to get this
to work properly or they would have enabled the setjmp/longjmp functionality.

Just a thought...