home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / mod.std.unix.v2 / text0004.txt < prev    next >
Encoding:
Internet Message Format  |  1987-06-30  |  2.2 KB
  1. Date:     Fri, 20 Sep 85 11:53:29 EDT
  2. From: Doug Gwyn (VLD/VMB) <gwyn@BRL.ARPA>
  3. To: std-unix@ut-sally.ARPA
  4.  
  5. I checked with X3J11 and the proposed change in the declaration of
  6. user signal-handling functions has a problem.
  7.  
  8. The proposed change in the declared type of a signal handler was to:
  9.     void func( int sig, ... );
  10. where the ", ..." was intended to allow provision of additional
  11. information (such as PC at time of fault) to the signal handler,
  12. in a "signal and implementation dependent" way.
  13.  
  14. This is a nice idea, but according to X3J11 in order to guarantee
  15. portability one would have to define all signal handlers with the
  16. same ", ..." notation.  The fundamental reason behind this
  17. requirement is that some C implementations will use a different
  18. function parameter passing mechanism for variable parameter lists
  19. than for regular lists.
  20.  
  21. This means that existing code such as
  22.     void
  23.     onintr( sig )            /* SIGINT catcher */
  24.         int    sig;
  25.         {
  26.         do_something_with( sig );
  27.         }
  28. would officially be broken.  (Of course, many UNIX C implementations
  29. on "nice" architectures would continue to work anyway.)
  30.  
  31. In order to avoid having to recode signal handlers to look like
  32.     void
  33.     onintr( int sig, ... )        /* SIGINT catcher */
  34.         {
  35.         do_something_with( sig );
  36.         }
  37. I recommend that the "optional" extra signal handler function
  38. parameter(s) be removed from the proposed specification.  I agree
  39. that a better signal interface would be desirable, and suggest
  40. that the "real time extensions" subcommittee should consider this
  41. issue (hopefully, they will use a different mechanism such as
  42. 4.2BSD's if they need to change the semantics).
  43.  
  44. Incidentally, the reason that this variable parameter list issue
  45. is not a problem with open(), execl(), printf(), etc. is that the
  46. application developer ("user") sees those functions from the
  47. outside only, not from the inside (i.e., he uses their declarations
  48. but does not have to provide a definition).  For brand-new
  49. facilities there is also no problem, since X3J11 provides a
  50. "stdargs" mechanism to provide a portable way to implement such
  51. function definitions.  It is only when compatibility with past
  52. function definitions is involved that a problem can arise.
  53.  
  54. Volume-Number: Volume 2, Number 5
  55.  
  56.