home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / lang / c / 18505 < prev    next >
Encoding:
Internet Message Format  |  1992-12-16  |  1.4 KB
  1. Path: sparky!uunet!sdrc!thor!scjones
  2. From: scjones@thor.sdrc.com (Larry Jones)
  3. Newsgroups: comp.lang.c
  4. Subject: Re: longjumping out of a signal handler
  5. Message-ID: <2405@sdrc.COM>
  6. Date: 16 Dec 92 22:59:14 GMT
  7. References: <1992Dec09.185512.33137@spillman.uucp> <4233@dozo.and.nl>
  8. Sender: news@sdrc.COM
  9. Lines: 21
  10.  
  11. In article <4233@dozo.and.nl>, jos@and.nl (Jos Horsmeier) writes:
  12. > True, all true, as far as I can find in the ANSI C standard, it's
  13. > perfectly safe now to use longjmp() from within a signal function.
  14. > No special prerequisites are necessary ...
  15.  
  16. Remember that the ANSI C Standard really only talks about *synchronous*
  17. signals that occur because the program called raise().  As far as
  18. *asynchronous* signals (which are the interesting kind), what it says
  19. (in 4.7.1.1 The signal Function) is:
  20.  
  21.     ...the behavior is undefined if the signal handler calls
  22.     any function in the standard library other than the signal
  23.     function itself (with a first argument of the signal number
  24.     corresponding to the signal that caused the invocation of
  25.     the handler) or refers to any object with static storage
  26.     duration other than by assigning a value to a static storage
  27.     duration variable of type volatile sig_atomic_t.
  28. ----
  29. Larry Jones, SDRC, 2000 Eastman Dr., Milford, OH  45150-2789  513-576-2070
  30. larry.jones@sdrc.com  or  ...uunet!sdrc!larry.jones
  31. Geez, I gotta have a REASON for everything? -- Calvin
  32.