home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / windows / x / 19303 < prev    next >
Encoding:
Text File  |  1992-11-18  |  2.5 KB  |  49 lines
  1. Newsgroups: comp.windows.x
  2. Path: sparky!uunet!charon.amdahl.com!pacbell.com!ames!saimiri.primate.wisc.edu!zaphod.mps.ohio-state.edu!darwin.sura.net!jvnc.net!yale.edu!cs.yale.edu!rtnmr.chem.yale.edu!rescorla
  3. From: rescorla@rtnmr.chem.yale.edu (Eric Rescorla)
  4. Subject: Re: FLAME, FLAME ON X!!!
  5. Message-ID: <1992Nov18.194905.16185@cs.yale.edu>
  6. Sender: news@cs.yale.edu (Usenet News)
  7. Nntp-Posting-Host: rtnmr.chem.yale.edu
  8. Organization: Rescorla for himself.
  9. References: <1683@igd.fhg.de> <1992Nov9.235741.25166@dsd.es.com> <1992Nov18.183826.2652@lsl.co.uk>
  10. Date: Wed, 18 Nov 1992 19:49:05 GMT
  11. Lines: 36
  12.  
  13. In article <1992Nov18.183826.2652@lsl.co.uk> snail@lsl.co.uk writes:
  14. >In article <1992Nov9.235741.25166@dsd.es.com>, pmartz@dsd.es.com (Paul Martz) writes:
  15. >> Care to tell us in which vendor's X is this a bug? I've certainly
  16. >> never heard of it before.
  17. >
  18. >This is NOT an X bug. This is a feature of C's memory allocation routines. When
  19. >memory is allocated, if there is no spare space, the C library asks the
  20. >OS for more memory, but when memory is freed, C does not give the memory back
  21. >to the OS. As a result programs can only get bigger, or stay the same size as
  22. >memory as allocated and freed. The program gets bigger every time memory is
  23. >requested and cannot be allocate out of the current free heap space. When this
  24. >happens the C library ask the OS for more memory. When the memory is freed,
  25. >it is returned to the free memory heap, not the OS.
  26. >
  27. >*** This is not a UNIX feature, this is a C feature, to be found on PCs, Ataris
  28. >, UNIX boxes, VAXes etc. This a feature, ie: C is designed this way. ****
  29. >
  30. >My apologies for replying to this thread 3 days late, someone has probably said
  31. >this before. But then again, maybe they haven't.
  32. I hope not. It's wrong. It is not part of the definition of the
  33. C language or of malloc(3). It happens that it is a very common way to
  34. do things, because sbrk(2) calls are expensive and it's not obviously
  35. worthwhile to return memory to the system. (This is on Unix. I imagine
  36. that similar conditions obtain on other machine.)
  37.  
  38. However, it would be quite legal to return the memory to the OS. I believe
  39. Jim Frost mentioned previously that he had in fact written such a malloc
  40. routine.
  41. -Ekr
  42.  
  43.  
  44. -- 
  45. -------------------------------------------------------------------------------
  46. Eric Rescorla, DoD#431 (Nighthawk S)              rescorla@rtnmr.chem.yale.edu
  47. Former chemist now CM400 mechanic                 ekr@eitech.com(preferred)
  48.                 "Meet the new boss, same as the old boss."
  49.