by Mitch Gorm » Fri, 20 Mar 1992 06:09:50
Why would one use these critters? The man pages don't give any sort
of example or rationale.
Would they be used to longjmp into a signal handling routine?
TIA.
Mitch
"If I had my way, I'd just walk through those doors,
and wander down the Champs d'Elysees..."
by Guy Harr » Sat, 21 Mar 1992 09:12:22
One would use them if one's program depends on the "setjmp"-likeQuote:> Why would one use these critters?
POSIX says those routines should *not* save or restore the signal mask,
so in POSIX-compliant environments you have to use "sigsetjmp()" and
"siglongjmp()" with the second argument to "sigsetjmp" being non-zero.
E.g., one would use these routines if one would expect them to be run on
systems other than current BSD systems, or in the non-BSD environments
of multiple-environment systems; while the *current* BSD versions of
"setjmp()" and "longjmp()" save and restore the signal mask, future ones
will probably not do so, as future BSDs will probably be
POSIX-compliant.
(If you want to debate whether requiring that "setjmp()" and "longjmp()"
not save and restore the signal mask is a good idea, leave me out of the
debate - I no longer care, at this point, so go debate the POSIX folks
instead.)
by Chuck Kari » Sat, 21 Mar 1992 13:13:44
>One would use them if one's program depends on the "setjmp"-like
>operation saving the current value of the "signal mask", and the
>"longjmp"-like operation restoring that value, and having the program
>run correctly when compiled in environments where "setjmp()" and
>"longjmp()" don't save or restore that signal mask.
This is not true. setjmp() and longjmp() are specifiedQuote:>POSIX says those routines should *not* save or restore the signal mask,
>so in POSIX-compliant environments you have to use "sigsetjmp()" and
>"siglongjmp()" with the second argument to "sigsetjmp" being non-zero.
The 4.2 BSD, 4.3 BSD, and SVR3 versions of setjmp() andQuote:>E.g., one would use these routines if one would expect them to be run on
>systems other than current BSD systems, or in the non-BSD environments
>of multiple-environment systems; while the *current* BSD versions of
>"setjmp()" and "longjmp()" save and restore the signal mask, future ones
>will probably not do so, as future BSDs will probably be
>POSIX-compliant.
Mindcraft, Inc. (415) 323-9000
by Guy Harr » Fri, 27 Mar 1992 10:50:22
Correct. I knew there was *some* problem with the signal mask andQuote:>This is not true. setjmp() and longjmp() are specified
>both by POSIX.1 and by Standard C. Neither standard says
>whether setjmp() saves and longjmp() restores the signal
>mask.
The conclusion that one would use "sigsetjmp()" and "siglongjmp()" if
one wants to make sure the signal mask is saved and restored still holds
if one plans to use those calls in systems where "setjmp()" and
"longjmp()" don't save or restore the signal mask.
I.e., if you're writing code that you want to run on a reasonably wide
range of POSIX-compliant systems, and that code depends on having a
"setjmp"-like and a "longjmp"-like operation that save and restore,
respectively, the signal mask, you're strongly advised to use
"sigsetjmp()" and "siglongjmp()".
Which says pretty much the same thing - they're there for code thatQuote:>The 4.2 BSD, 4.3 BSD, and SVR3 versions of setjmp() and
>longjmp() all match the POSIX.1 specification. See B.8.3.1
>of the Rationale for POSIX.1.
1. long/set jmp and buffered i/o
hi,
i am working under IRIX 3.3, it is a flavor of SYS V-3 unix with
some bsd extensions.
my problem is this: i am doing a while loop that get's characters
from stdin (getchar()) until EOF is reached. i am also catching
SIGINT with a longjmp in the handler that takes me back to the loop.
basically the code looks like this:
if (signal(SIGINT,SIG_IGN) !=SIG_IGN)
signal(SIGINT,handler);
while((temp=getchar)!=EOF){
foo[b]=temp;
if (setjmp(env)==0) {
blah;
b++;
}
and then the following handler:
handler(sig)
int sig;
{
signal(sig,SIG_IGN);
blah;
signal(sig,handler);
longjmp(env,1)
the problem is this: the first line of buffered input causes problems;
the code as presented causes a core dump if cntl-c is pressed before the
first line feed. the reason is obvious (i think :) ), the handler is
longjmp-ing before it ever setjmp-s. my first solution was to put
this line before the while loop starts:
ungetc('\n',stdin);
well this avoids the core dump, but now we lose everything on the first
line, if cntl-c is hit before the first line feed is pressed. obviously
this solution is not optimum...
does anyone have any solutions on how to preserve the characters that
have not yet been read into the array, foo?
thanks,
jonathan.
--
Virtual pizza Delivery (tm)::faxed in 30 cycles or less or you get it
FREE!!!
2. Want to find a job of Linux and Cisco
4. Samba w/ 2 subnets, 1 interface?
5. NYC LOCAL: Thursday 16 August 2001 NYSIA Open Source SIG: Joseph McElroy Introduces the New SIG
6. sendmail and libc.so.4.6.27 problem
7. long long & long double types in Linux GCC
9. RH7.2 2.4.X off_t: long or long long?
10. Linux has a long, long, long way to go
11. Fatal Sig 11 & CMOS setting
12. Setting up X! - sig.dat (1/1)
13. possible to set sig handler for child threads