home *** CD-ROM | disk | FTP | other *** search
- Newsgroups: comp.unix.aix
- Path: sparky!uunet!sun-barr!cs.utexas.edu!torn!newshost.uwo.ca!newshost.uwo.ca!oink
- From: oink@newshost.uwo.ca (Test Account)
- Subject: Re: SUMMARY: dbx problems
- Organization: The University of Western Ontario, London, Canada.
- Date: Sun, 26 Jul 1992 08:37:41 GMT
- Message-ID: <OINK.92Jul26033741@julian.newshost.uwo.ca>
- In-Reply-To: marca@void.ncsa.uiuc.edu's message of 24 Jul 92 00:23:41 GMT
- References: <1992Jul23.202224.29736@ief.itg.ti.com> <BrvAFJ.6oM@news.cso.uiuc.edu>
- Sender: news@julian.uwo.ca (USENET News System)
- Nntp-Posting-Host: julian.uwo.ca
- Lines: 29
-
- In article <BrvAFJ.6oM@news.cso.uiuc.edu> marca@void.ncsa.uiuc.edu (Marc Andreessen) writes:
-
- I believe). Also, 3.1 malloc would clear all memory it allocated to 0;
- 3.2 malloc does not. (Normally, malloc isn't supposed to do this -
- but calloc is.)
-
- My experience has shown that this is simply not true. Although it probably is
- true of malloc()ed memory from the heap, it is certainly NOT true of recently
- free()ed amd re-malloc()ed memory. Certainly not something to count on!
-
- Actually, the big change that I did not expect with the new malloc behaviour
- is that free()ed memory is no longer valid. Many programmers (for historical
- reasons I guess) assume that constructs like the following should work:
-
- while (ptr) {
- free(ptr);
- ptr = ptr->next;
- }
-
- This will not work under with MALLOCTYPE=3.2 environment (and IMHO it
- should never have worked, but that is another argument).
-
- Hope this helps,
-
- And this,
-
- Marc
-
- cheerskinch
-