home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / std / c / 2365 < prev    next >
Encoding:
Internet Message Format  |  1992-07-26  |  3.3 KB
  1. Path: sparky!uunet!cs.utexas.edu!swrinde!mips!zaphod.mps.ohio-state.edu!cis.ohio-state.edu!ucbvax!dog.ee.lbl.gov!horse.ee.lbl.gov!torek
  2. From: torek@horse.ee.lbl.gov (Chris Torek)
  3. Newsgroups: comp.std.c
  4. Subject: Re: Function Prototypes: Don't they force casts?
  5. Message-ID: <24914@dog.ee.lbl.gov>
  6. Date: 26 Jul 92 21:06:09 GMT
  7. References: <OINK.92Jul26032212@julian.newshost.uwo.ca>
  8. Reply-To: torek@horse.ee.lbl.gov (Chris Torek)
  9. Organization: Lawrence Berkeley Laboratory, Berkeley
  10. Lines: 79
  11. NNTP-Posting-Host: 128.3.112.15
  12.  
  13. In article <OINK.92Jul26032212@julian.newshost.uwo.ca>
  14. oink@newshost.uwo.ca (Test Account) writes:
  15. >#include <signal.h>
  16. >#include "myproto.h" /* This included many prototypes, but of particular
  17. >interest here is: void memory_fault(void); */
  18. >[...]
  19. >    if ((int) signal(SIGSEGV, memory_fault) < 0) {
  20. >        perror("Trouble initializing SEGV routine");
  21. >        exit(-1);
  22. >    }
  23.  
  24. >Under AIX 3.2 using c89, this produces a diagnostic about incompatible types:
  25.  
  26. It certainly should!
  27.  
  28. >int and pointer (don't have the exact text handy, but I hope you get the
  29. >idea). This occurs IFF memory_fault() is declared AFTER its use or in another
  30. >module, if it is declared before its use there is no diagnostic.
  31.  
  32. This is wrong (by which I mean `this behavior is nonconformant').
  33. In any case, if myproto.h includes a prototype, the function is (as
  34. it must be) declared before its name is used.  Perhaps you mean
  35. `defined'?
  36.  
  37. >The fix is simple, ((void *) memory_fault) works fine but I THINK that
  38. >it is unnecessary.
  39.  
  40. It is not only unnecessary, it is also wrong and should cause a
  41. diagnostic.  The type `void *' is not assignment-compatible with any
  42. pointer-to-function type.
  43.  
  44. The subject line asks whether prototypes `force casts'.  No.  Prototypes
  45. provide *assignment context* and the legality of any argument for which
  46. there is a prototype is identical to that for an assignment to a variable
  47. of the same type as in the prototype (section 3.3.2.2, p. 42, ll. 10--16).
  48.  
  49. Now, signal() takes, as its second argument, a value of type:
  50.  
  51.     pointer to function (of one arg: int) returning void
  52.  
  53. (section 4.7.1.1).   The `memory_fault' prototype says that
  54. memory_fault is a
  55.  
  56.     function (of no args) returning void
  57.  
  58. so that mentioning it produces a pointer to this.  These are not
  59. assignment-compatible (section 3.3.16.1) and this requires a diagnostic.
  60.  
  61. The diagnostic can be eliminated (at the cost of undefined runtime
  62. behavior, i.e., without fixing the bug) with:
  63.  
  64.     signal(SIGSEGV, (void (*)(int))memory_fault)
  65.  
  66. The correct fix, of course, is to change memory_fault so that it takes
  67. exactly one `int' argument, and change the prototype correspondingly.
  68.  
  69. In any case, the test
  70.  
  71.     if ((int)signal(...) < 0) ...
  72.  
  73. is quite wrong, and will fail on machines on which function pointers
  74. appear negative after conversion to int.  (I have a fuzzy memory that
  75. suggests this may have been the case on some Elxsi machine, for
  76. instance.)  It should be
  77.  
  78.     if (signal(...) == SIG_ERR) ...
  79.  
  80. If you have a pre-ANSI system that does not define SIG_ERR, this will
  81. probably work:
  82.  
  83.     #ifndef SIG_ERR
  84.     #define    SIG_ERR ((void (*)(int))-1)
  85.     #endif
  86.  
  87. (The reason for using SIG_ERR in the first place is that the above is,
  88. obviously, not portable.  I claim only that it will `probably work'.)
  89. -- 
  90. In-Real-Life: Chris Torek, Lawrence Berkeley Lab CSE/EE (+1 510 486 5427)
  91. Berkeley, CA        Domain:    torek@ee.lbl.gov
  92.