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