home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / lang / c / 19998 < prev    next >
Encoding:
Internet Message Format  |  1993-01-21  |  2.9 KB
  1. Path: sparky!uunet!olivea!sgigate!sgiblab!munnari.oz.au!yarrina.connect.com.au!warrane.connect.com.au!g2syd!senerat
  2. From: senerat@g2syd.genasys.com.au (Senerat Rajakaruna)
  3. Newsgroups: comp.lang.c
  4. Subject: Re: Btree, or Linked List Questions
  5. Message-ID: <1993Jan21.015358.24137@g2syd.genasys.com.au>
  6. Date: 21 Jan 93 01:53:58 GMT
  7. References: <C13soz.73L@murphy.com>
  8. Organization: Genasys II, Sydney, Australia
  9. Lines: 72
  10.  
  11. In article <C13soz.73L@murphy.com> gregb@murphy.com (Greg Banschbach (Unigroup of New York)) writes:
  12. >
  13. >
  14. >    Dear fellow C programmers,
  15. >
  16. >        I have 2 questions regarding code I have seen:
  17. >
  18. >    1.    When you create a Btree, most books detail how to 
  19. >          do deletions and insertions to add to the tree, and 
  20. >          it usually involves using "malloc" to create a node,
  21. >          and "free" to delete it.     I saw some code once 
  22. >          where, when they were finished with the tree, they 
  23. >          just said  free(tree).     I thought you had to free
  24. >          each individual node throughout the tree before you 
  25. >          could free the root node.     What gives ?    
  26. >
  27. >    2.     What happens with linked lists ?   Do you simply 
  28. >        " free " the head - and the rest of the chain is
  29. >        de-allocated ?
  30. >
  31. >    Please try to support your answers with either quotes from 
  32. >    a known source OR something equally as secure ( proven ). 
  33. >
  34. >    Please e-mail me at:     uunet!murphy!galunix!greg  OR
  35. >                 gregb@murphy.com
  36. >
  37. >    Thanks for the input guys 
  38. >    Greg Banschbach
  39. >    ( Not an employee at murphy ).
  40.  
  41. Blocks of memory obtained dynamically via calls to malloc or calloc should
  42. be freed by calling free() if dynamic memory is to be maintained for wider use.
  43. Each such allocation will cause the processes pre-allocated dynamic memory
  44. space to be reduced and it will subsequently run out if not freed. Once freed
  45. memory space can be regained via calls to malloc or calloc.
  46.  
  47.     'There are no restrictions on the order in which space is freed,
  48.      but it is a ghastly error to free something not obtained by calling
  49.      calloc or malloc'
  50.  
  51.         - The C Programming Language by K & R (ANSI C) - p167
  52.  
  53. Freeing the head of a linked list or a Btree only frees the space reserved
  54. in storing the address of the structure as defined for the head. Individual
  55. space gained via calls to malloc or calloc must be freed together with their
  56. head to save the precious dynamic memory.
  57.  
  58. The right way to free a linked list is to save the next pointer of head 
  59. before freeing:
  60.     
  61.     LIST *p, *q;
  62.  
  63.     for (p = head; p != NULL; p = q)
  64.     {
  65.         q = p -> next;
  66.  
  67.         /* free any sub-elements of current head */
  68.         FreeData(p);
  69.         (void) free((void*) p);
  70.     }
  71.  
  72.     /* reset head */
  73.     head = (LIST *) NULL;
  74.  
  75. See K & R pages 185 - 189 for a detailed description of how memory lists are
  76. handled by the operating system. 
  77.  
  78.  
  79. Senerat Rajakaruna  |  Genasys II Pty Ltd
  80.                     |  13th Level, 33 Berry St, North Sydney, NSW, Australia
  81.                     |  Phone:    +61-2-954-0022 (-9930 FAX)
  82.                     |  Internet: senerat@g2syd.genasys.com.au
  83.