home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / sys / sgi / 12447 < prev    next >
Encoding:
Internet Message Format  |  1992-08-14  |  1.7 KB
  1. Path: sparky!uunet!cs.utexas.edu!sdd.hp.com!uakari.primate.wisc.edu!ames!sgi!quasar.wpd.sgi.com!davea
  2. From: davea@quasar.wpd.sgi.com (David B.Anderson)
  3. Newsgroups: comp.sys.sgi
  4. Subject: Re: Possible bug in c-compiler ?
  5. Message-ID: <oj35voc@sgi.sgi.com>
  6. Date: 15 Aug 92 00:42:38 GMT
  7. Sender: davea@quasar.wpd.sgi.com
  8. Organization: Silicon Graphics, Inc.  Mountain View, CA
  9. Lines: 48
  10.  
  11. In article <1992Aug14.165251.20524@sni.ca> ash@sni.ca (Ashwin Palekar) writes:
  12. >ON: IRIX 4.0.1 11150233 IP12
  13. >
  14. >Problem Description:
  15. >~~~~~~~~~~~~~~~~~~~~
  16. >    The software works with debug version (default compiler option)
  17. >and dumps core in optimised version (-O).
  18. >
  19. >Problem Analysis :
  20. >~~~~~~~~~~~~~~~~~
  21. >    the code has the following logic.
  22. >{
  23. >    struct xyz *variable=NULL;
  24. >    setjmp();
  25. >    
  26. >    variable = ... allocate memory.
  27. >    free (variable)
  28. >    variable = NULL; 
  29. >
  30. >    longjmp(Go to statement shown next)
  31. >
  32. >    if variable != NULL free(variable)
  33. >    
  34. >}
  35. >
  36. >In debug mode "variable" is equal to NULL after longjmp.
  37. >In optimised mode "variable" it is not NULL after longjmp tries to free it
  38. >resulting in core dump.
  39. >
  40. >IMP: This same behaviour is noticed on mips platform (maybe because of 
  41. >same compiler).
  42.  
  43. The compiler is not broken. Your code is making an unwarranted assumption.
  44.  
  45. Loosely speaking: You want to declare any variable that he  is altered
  46. in a function doing setjmp volatile.  Example:
  47.  
  48.     struct xyz * volatile variable = NULL;
  49.  
  50. In the absence of "volatile" the compiler is free to do optimizations
  51. that will break your code.
  52.  
  53. Possible starting points for RTFM-ing:
  54.     ANSI C Std section 4.6.1 and 4.6.2,   
  55.     ISO C Std 7.6.1 7.6.2
  56.     K&R2, section B8, page 254.
  57.  
  58. [ David B. Anderson             (415)390-1548             davea@sgi.com ]
  59.