home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / lang / c / 11804 < prev    next >
Encoding:
Internet Message Format  |  1992-07-31  |  1.6 KB

  1. Path: sparky!uunet!mcsun!sun4nl!and!jos
  2. From: jos@and.nl (Jos Horsmeier)
  3. Newsgroups: comp.lang.c
  4. Subject: Re: Pointers to freed memory
  5. Message-ID: <3185@dozo.and.nl>
  6. Date: 31 Jul 92 08:12:14 GMT
  7. References: <1992Jul29.205834.11308@hubcap.clemson.edu> <3179@dozo.and.nl> <1992Jul30.164035.7349@taumet.com>
  8. Organization: AND Software BV Rotterdam
  9. Lines: 32
  10.  
  11. In article <1992Jul30.164035.7349@taumet.com> steve@taumet.com (Steve Clamage) writes:
  12. |jos@and.nl (Jos Horsmeier) writes:
  13. |
  14. |>In article <1992Jul29.205834.11308@hubcap.clemson.edu> mjs@hubcap.clemson.edu (M. J. Saltzman) writes:
  15. |>|I know that a pointer to freed memory should never be dereferenced, 
  16. |>|but is it standard-conforming to assign or do arithmetic with such
  17. |>|pointers?
  18. |
  19. |>As long as you do not dereference such a pointer (as you indicated
  20. |>yourself,) everything is fine.  If pointer q contained a valid pointer
  21. |>value _before_ the call to free(), it'll contain a valid pointer value
  22. |>_after_ the call.
  23. |
  24. |This is not necessarily the case, although it is safe for many common
  25. |architectures.
  26. |
  27. |The C Standard states that the value of the pointer after a call to free
  28. |is 'indeterminate'.  This means that just reading the value might
  29. |produce a runtime fault.
  30.  
  31. [ example deleted ... ]
  32.  
  33. You're right. Absolutely right. Someone else e-mailed me about this and
  34. told me exactly the same thing. I am stunned ... I never could have 
  35. imagined a processor architecture where a validation on an address
  36. value would be done while just _loading_ that particular value. But
  37. such (ugly) animals seem to exist; I've never had the `pleasure'
  38. to meet one ...
  39.  
  40. kind regards,
  41.  
  42. Jos aka jos@and.nl
  43.