home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / lang / c / 18479 < prev    next >
Encoding:
Internet Message Format  |  1992-12-16  |  2.6 KB
  1. Path: sparky!uunet!elroy.jpl.nasa.gov!usc!rpi!uwm.edu!linac!pacific.mps.ohio-state.edu!cis.ohio-state.edu!magnus.acs.ohio-state.edu!usenet.ins.cwru.edu!agate!dog.ee.lbl.gov!horse.ee.lbl.gov!torek
  2. From: torek@horse.ee.lbl.gov (Chris Torek)
  3. Newsgroups: comp.lang.c
  4. Subject: Re: Signal() function & CTRL-C checking...
  5. Date: 16 Dec 1992 19:01:08 GMT
  6. Organization: Lawrence Berkeley Laboratory, Berkeley CA
  7. Lines: 59
  8. Message-ID: <28013@dog.ee.lbl.gov>
  9. References: <1992Dec16.053939.1014@monu6.cc.monash.edu.au>
  10. NNTP-Posting-Host: 128.3.112.15
  11.  
  12. In article <1992Dec16.053939.1014@monu6.cc.monash.edu.au>
  13. alien@yoyo.cc.monash.edu.au (Diego Barros) writes:
  14. >Could someone please explain what exactly the signal prototype in the
  15. >signal.h file is declaring (in english?!?) :)
  16.  
  17. ><signal.h>    extern void (*signal(int __sig, (*__func)(int)))(int);
  18.  
  19. You left out a `void' (either that, or your <signal.h> is broken):
  20.  
  21. void    (*signal(int, void (*)(int)))(int);
  22.  
  23. (note, I have broken up long lines below)
  24.     % cdecl
  25.     cdecl> explain void (*signal(int, void (*)(int)))(int)
  26.     declare signal as function
  27.         (int, pointer to function (int) returning void)
  28.     returning pointer to function (int) returning void
  29.  
  30. If your tabstops are set properly :-) (or even if not) a certain
  31. symmetry here should jump out at you: signal's second argument has
  32. the exact same type as signal's return value.  If you take the
  33. `pointer to's off that type, you get something quite simple:
  34.  
  35.     function (int) returning void
  36.  
  37. or, in C:
  38.  
  39.     void myfunc(int some_parameter) { ... }
  40.  
  41. These are valid `signal functions'.  When a signal occurs, if the
  42. signal has been attached to `myfunc', `myfunc' will get called with
  43. some_parameter set to the signal number.  Hence:
  44.  
  45.     (void)signal(SIGINT, myfunc);
  46.     raise(SIGINT);
  47.  
  48. will call myfunc() with SIGINT, almost as if you replaced the raise()
  49. with
  50.  
  51.     myfunc(SIGINT);
  52.  
  53. The return value from signal() is simply a pointer to the previous
  54. function, if any, or one of the special values (SIG_IGN, SIG_DFL,
  55. SIG_ERR).
  56.  
  57. If you call a signal handler yourself, through raise(), it is fairly
  58. safe to do just about anything in that handler.  If you trap `system'
  59. signals (SIGINT, SIGALRM, etc) and receive one of those, very little
  60. is safe.  Portable, reliable programs generally just set a flag (of
  61. type volatile sig_atomic_t) and return; the remainder of such programs
  62. tends to be peppered with checks of the form:
  63.  
  64.     if (we_got_an_interrupt) take_care_of_it();
  65.  
  66. (Most interactive programs have some sort of central loop, so that
  67. one does not need very many `if (we_got_an_interrupt)'s.)
  68. -- 
  69. In-Real-Life: Chris Torek, Lawrence Berkeley Lab CSE/EE (+1 510 486 5427)
  70. Berkeley, CA        Domain:    torek@ee.lbl.gov
  71.