Should you free your pointers?

Discussion in 'C Programming' started by Billy Mays, Jun 24, 2011.

  1. Billy Mays

    Billy Mays Guest

    In the case where you know that your program will be terminating after
    it is done using the pointers, should you even bother freeing the space up?

    Example:
    int main(void)
    {
    int i, * data;
    data = malloc(sizeof(int) * 100);
    if(data) {
    for(i = 0; i < 100; i++) {
    data = i'
    }
    }
    /* free(data) ? */
    return 0;
    }

    --
    Bill
    Billy Mays, Jun 24, 2011
    #1
    1. Advertising

  2. Billy Mays

    Shao Miller Guest

    On 6/24/2011 16:41, Billy Mays wrote:
    > In the case where you know that your program will be terminating after
    > it is done using the pointers, should you even bother freeing the space up?
    >
    > Example:
    > int main(void)
    > {
    > int i, * data;
    > data = malloc(sizeof(int) * 100);
    > if(data) {
    > for(i = 0; i < 100; i++) {
    > data = i'
    > }
    > }
    > /* free(data) ? */
    > return 0;
    > }


    I've seen arguments for:
    - Program performance
    - Program size

    And against:
    - Programmer habit
    - Cases where program termination doesn't free memory allocated by the
    program

    I think it's a worth-while habit to 'free' them, in general.
    Shao Miller, Jun 24, 2011
    #2
    1. Advertising

  3. Billy Mays

    Nobody Guest

    On Fri, 24 Jun 2011 16:41:00 -0400, Billy Mays wrote:

    > In the case where you know that your program will be terminating after
    > it is done using the pointers, should you even bother freeing the space up?


    No.

    In complex programs where freeing data may be mixed with other clean-up,
    I may set __free_hook to an empty function when termination is imminent.
    Nobody, Jun 24, 2011
    #3
  4. Billy Mays

    Shao Miller Guest

    On 6/24/2011 16:51, Shao Miller wrote:
    > On 6/24/2011 16:41, Billy Mays wrote:
    >> In the case where you know that your program will be terminating after
    >> it is done using the pointers, should you even bother freeing the
    >> space up?
    >>
    >> Example:
    >> int main(void)
    >> {
    >> int i, * data;
    >> data = malloc(sizeof(int) * 100);
    >> if(data) {
    >> for(i = 0; i < 100; i++) {
    >> data = i'
    >> }
    >> }
    >> /* free(data) ? */
    >> return 0;
    >> }

    >
    > I've seen arguments for:
    > - Program performance
    > - Program size
    >
    > And against:
    > - Programmer habit
    > - Cases where program termination doesn't free memory allocated by the
    > program
    >
    > I think it's a worth-while habit to 'free' them, in general.


    Uh, I meant "for not bothering" and "against not bothering." :)
    Shao Miller, Jun 24, 2011
    #4
  5. Billy Mays

    Ben Pfaff Guest

    Billy Mays <> writes:

    > In the case where you know that your program will be terminating after
    > it is done using the pointers, should you even bother freeing the
    > space up?


    One reason that I sometimes bother is that it's very clear that a
    program that frees all of its memory does not have a memory leak
    (when I use a tool that reports memory statistics at program
    exit).
    --
    Ben Pfaff
    http://benpfaff.org
    Ben Pfaff, Jun 24, 2011
    #5
  6. Billy Mays

    Ian Collins Guest

    On 06/25/11 08:41 AM, Billy Mays wrote:
    > In the case where you know that your program will be terminating after
    > it is done using the pointers, should you even bother freeing the space up?


    Code fragments that will never be reused often are, so get into good
    habits early!

    --
    Ian Collins
    Ian Collins, Jun 24, 2011
    #6
  7. On 6/24/2011 4:41 PM, Billy Mays wrote:
    > In the case where you know that your program will be terminating after
    > it is done using the pointers, should you even bother freeing the space up?


    You should always free any space you have allocated. There is no
    guarantee that the OS will do it for you. Even if the OS you are
    currently using claims it will do so, relying on such behavior makes
    your code non-portable and there is no warrant in the C standard for
    expecting otherwise (since the C standard can hardly decree such this
    for the OS).

    > Example:


    No example is needed.
    Martin Ambuhl, Jun 25, 2011
    #7
  8. On 6/24/2011 4:53 PM, Nobody wrote:
    > On Fri, 24 Jun 2011 16:41:00 -0400, Billy Mays wrote:
    >
    >> In the case where you know that your program will be terminating after
    >> it is done using the pointers, should you even bother freeing the space up?

    >
    > No.
    >
    > In complex programs where freeing data may be mixed with other clean-up,
    > I may set __free_hook to an empty function when termination is imminent.
    >


    It is appropriate that this incorrect answer came from "Nobody".
    Martin Ambuhl, Jun 25, 2011
    #8
  9. Billy Mays

    Eric Sosman Guest

    On 6/24/2011 4:41 PM, Billy Mays wrote:
    > In the case where you know that your program will be terminating after
    > it is done using the pointers, should you even bother freeing the space up?


    This is Question 7.24 on the comp.lang.c Frequently Asked
    Questions (FAQ) page at <http://www.c-faq.com/>.

    --
    Eric Sosman
    d
    Eric Sosman, Jun 25, 2011
    #9
  10. Billy Mays

    James Kuyper Guest

    On 06/24/2011 04:41 PM, Billy Mays wrote:
    > In the case where you know that your program will be terminating after
    > it is done using the pointers, should you even bother freeing the space up?
    >
    > Example:
    > int main(void)
    > {
    > int i, * data;
    > data = malloc(sizeof(int) * 100);
    > if(data) {
    > for(i = 0; i < 100; i++) {
    > data = i'
    > }
    > }
    > /* free(data) ? */
    > return 0;
    > }


    It's not necessary, but I think it's easier to not make a special case
    of main(); the rules for creating well-written code are easier to
    remember if they don't have more special cases than they have to.

    Also, there's always the possibility that code from main() may someday
    get moved off to another function; if that code already contains
    properly connected malloc() and free() calls, that's one less thing to
    worry about during the move.
    --
    James Kuyper
    James Kuyper, Jun 25, 2011
    #10
  11. Billy Mays

    Nobody Guest

    On Fri, 24 Jun 2011 22:07:46 -0400, James Kuyper wrote:

    >> In the case where you know that your program will be terminating after
    >> it is done using the pointers, should you even bother freeing the space up?


    > It's not necessary, but I think it's easier to not make a special case
    > of main(); the rules for creating well-written code are easier to
    > remember if they don't have more special cases than they have to.


    Sometimes, explicitly freeing memory requires added complexity in order
    to keep track of what needs to be freed. E.g. if you have linked data
    structures where you could have multiple pointers to a single block of
    memory, you have to take steps to avoid multiple free()s of a single
    block. Similarly if pointers can be to either static or dynamic data.

    Adding such complexity is especially pointless if it only comes into play
    upon termination, e.g. if you have complex structures which must exist in
    order for the program to perform its normal function.

    > Also, there's always the possibility that code from main() may someday
    > get moved off to another function; if that code already contains
    > properly connected malloc() and free() calls, that's one less thing to
    > worry about during the move.


    If the structure of the code is such that "pairing" malloc and free makes
    sense, I'll do it. But in that case, I may set __free_hook (glibc) or
    similar to point to an empty function once termination is assured. This
    also deals with external libraries which typically have to free()
    everything upon finalisation to be on the safe side.

    Meticulously free()ing memory when you know that the program is about to
    terminate is like rearranging the deckchairs as the Titanic is sinking.
    Such operations can often take far longer than is immediately apparent, as
    you often end up walking through memory which has long since been swapped
    out.
    Nobody, Jun 25, 2011
    #11
  12. In article <iu3d2t$qlh$>,
    Eric Sosman <> wrote:

    > On 6/24/2011 4:41 PM, Billy Mays wrote:
    > > In the case where you know that your program will be terminating after
    > > it is done using the pointers, should you even bother freeing the space up?

    >
    > This is Question 7.24 on the comp.lang.c Frequently Asked
    > Questions (FAQ) page at <http://www.c-faq.com/>.


    FAQ was once frequently answered questions.

    --
    Michael Press
    Michael Press, Jun 25, 2011
    #12
  13. Michael Press <> writes:
    > In article <iu3d2t$qlh$>,
    > Eric Sosman <> wrote:
    >
    >> On 6/24/2011 4:41 PM, Billy Mays wrote:
    >> > In the case where you know that your program will be terminating
    >> > after it is done using the pointers, should you even bother freeing
    >> > the space up?

    >>
    >> This is Question 7.24 on the comp.lang.c Frequently Asked
    >> Questions (FAQ) page at <http://www.c-faq.com/>.

    >
    > FAQ was once frequently answered questions.


    Um, it still is.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    Nokia
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
    Keith Thompson, Jun 25, 2011
    #13
  14. In article <iu2tf6$rm7$>,
    Shao Miller <> wrote:
    >On 6/24/2011 16:41, Billy Mays wrote:
    >> In the case where you know that your program will be terminating after
    >> it is done using the pointers, should you even bother freeing the space up?

    >
    >And against:
    >- Programmer habit
    >- Cases where program termination doesn't free memory allocated by the
    >program


    - Chances that your code will be re-purposed into some larger
    program that *won't* terminate any time soon and which will call
    your code repeatedly.

    --
    -Ed Falk,
    http://thespamdiaries.blogspot.com/
    Edward A. Falk, Jun 26, 2011
    #14
  15. In article <>,
    Keith Thompson <> wrote:

    > Michael Press <> writes:
    > > In article <iu3d2t$qlh$>,
    > > Eric Sosman <> wrote:
    > >
    > >> On 6/24/2011 4:41 PM, Billy Mays wrote:
    > >> > In the case where you know that your program will be terminating
    > >> > after it is done using the pointers, should you even bother freeing
    > >> > the space up?
    > >>
    > >> This is Question 7.24 on the comp.lang.c Frequently Asked
    > >> Questions (FAQ) page at <http://www.c-faq.com/>.

    > >
    > > FAQ was once frequently answered questions.

    >
    > Um, it still is.


    Um, that is what I am implying.

    --
    Michael Press
    Michael Press, Jun 26, 2011
    #15
  16. Michael Press <> writes:
    > In article <>,
    > Keith Thompson <> wrote:
    >
    >> Michael Press <> writes:
    >> > In article <iu3d2t$qlh$>,
    >> > Eric Sosman <> wrote:
    >> >
    >> >> On 6/24/2011 4:41 PM, Billy Mays wrote:
    >> >> > In the case where you know that your program will be terminating
    >> >> > after it is done using the pointers, should you even bother freeing
    >> >> > the space up?
    >> >>
    >> >> This is Question 7.24 on the comp.lang.c Frequently Asked
    >> >> Questions (FAQ) page at <http://www.c-faq.com/>.
    >> >
    >> > FAQ was once frequently answered questions.

    >>
    >> Um, it still is.

    >
    > Um, that is what I am implying.


    I'm afraid I've missed whatever point you're making.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    Nokia
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
    Keith Thompson, Jun 26, 2011
    #16
  17. Billy Mays

    Geoff Guest

    On Sun, 26 Jun 2011 13:08:24 -0700, Keith Thompson <>
    wrote:

    >Michael Press <> writes:
    >> In article <>,
    >> Keith Thompson <> wrote:
    >>
    >>> Michael Press <> writes:
    >>> > In article <iu3d2t$qlh$>,
    >>> > Eric Sosman <> wrote:
    >>> >
    >>> >> On 6/24/2011 4:41 PM, Billy Mays wrote:
    >>> >> > In the case where you know that your program will be terminating
    >>> >> > after it is done using the pointers, should you even bother freeing
    >>> >> > the space up?
    >>> >>
    >>> >> This is Question 7.24 on the comp.lang.c Frequently Asked
    >>> >> Questions (FAQ) page at <http://www.c-faq.com/>.
    >>> >
    >>> > FAQ was once frequently answered questions.
    >>>
    >>> Um, it still is.

    >>
    >> Um, that is what I am implying.

    >
    >I'm afraid I've missed whatever point you're making.


    I think it means it was once a frequently answered question, now it's
    in the FAQ so it no longer needs to be frequently answered. People can
    read the FAQ and don't need to ask it in the group. Either that, or he
    thinks the FAQ doesn't answer the question but FAQ stands for
    Frequently Asked Questions, without answers.
    Geoff, Jun 26, 2011
    #17
  18. In article <>,
    Keith Thompson <> wrote:

    > Michael Press <> writes:
    > > In article <>,
    > > Keith Thompson <> wrote:
    > >
    > >> Michael Press <> writes:
    > >> > In article <iu3d2t$qlh$>,
    > >> > Eric Sosman <> wrote:
    > >> >
    > >> >> On 6/24/2011 4:41 PM, Billy Mays wrote:
    > >> >> > In the case where you know that your program will be terminating
    > >> >> > after it is done using the pointers, should you even bother freeing
    > >> >> > the space up?
    > >> >>
    > >> >> This is Question 7.24 on the comp.lang.c Frequently Asked
    > >> >> Questions (FAQ) page at <http://www.c-faq.com/>.
    > >> >
    > >> > FAQ was once frequently answered questions.
    > >>
    > >> Um, it still is.

    > >
    > > Um, that is what I am implying.

    >
    > I'm afraid I've missed whatever point you're making.


    Reminding ES of this matter.

    --
    Michael Press
    Michael Press, Jun 27, 2011
    #18
  19. Billy Mays

    James Kuyper Guest

    On 06/25/2011 06:44 PM, Keith Thompson wrote:
    > Michael Press <> writes:
    >> In article <iu3d2t$qlh$>,
    >> Eric Sosman <> wrote:

    ....
    >>> This is Question 7.24 on the comp.lang.c Frequently Asked
    >>> Questions (FAQ) page at <http://www.c-faq.com/>.

    >>
    >> FAQ was once frequently answered questions.

    >
    > Um, it still is.


    I presume that he's commenting on the difference between "Asked" and
    "Answered".
    --
    James Kuyper
    James Kuyper, Jun 27, 2011
    #19
  20. James Kuyper <> writes:
    > On 06/25/2011 06:44 PM, Keith Thompson wrote:
    >> Michael Press <> writes:
    >>> In article <iu3d2t$qlh$>,
    >>> Eric Sosman <> wrote:

    > ...
    >>>> This is Question 7.24 on the comp.lang.c Frequently Asked
    >>>> Questions (FAQ) page at <http://www.c-faq.com/>.
    >>>
    >>> FAQ was once frequently answered questions.

    >>
    >> Um, it still is.

    >
    > I presume that he's commenting on the difference between "Asked" and
    > "Answered".


    I must admit I didn't notice that he changed the word from "asked" to
    "answered".

    Now that I've noticed, I'm not sure I've ever seen FAQ expanded
    to "Frequently Answered Questions" rather than "Frequently Asked
    Questions", and I still have no idea what Michael is getting at.
    Is he suggesting that Eric should have done something other than
    cite the FAQ?

    Sorry if I'm being dense.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    Nokia
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
    Keith Thompson, Jun 27, 2011
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. george
    Replies:
    0
    Views:
    1,065
    george
    Aug 29, 2008
  2. ........
    Replies:
    0
    Views:
    253
    ........
    Nov 6, 2010
  3. ........
    Replies:
    0
    Views:
    268
    ........
    Nov 7, 2010
  4. ........
    Replies:
    0
    Views:
    198
    ........
    Nov 7, 2010
  5. cerr

    pointers, pointers, pointers...

    cerr, Apr 7, 2011, in forum: C Programming
    Replies:
    12
    Views:
    642
Loading...

Share This Page