Calling free() on an uninitialised pointer?

Discussion in 'C Programming' started by santosh, Dec 4, 2005.

  1. santosh

    santosh Guest

    Hi,

    If I call free() with a uninitialised pointer, will the program
    state become undefined, or will free() return harmlessly?

    Incidentally, is there a way in Standard C to determine
    weather a pointer points to a valid block of allocated
    memory?

    Thanks for your time.
    santosh, Dec 4, 2005
    #1
    1. Advertising

  2. santosh wrote:

    > If I call free() with a uninitialised pointer, will the program
    > state become undefined, or will free() return harmlessly?


    a program that does this exhibits undefined behaviour. It *may*
    return harmlessly or give a segmentation error or something even
    nastier. Don't ever do this.

    what is safe is:-
    p = NULL;
    free(p);

    > Incidentally, is there a way in Standard C to determine
    > weather a pointer points to a valid block of allocated
    > memory?


    no


    --
    Nick Keighley

    I don't use drugs, my dreams are frightening enough. --M. C. Escher
    Nick Keighley, Dec 4, 2005
    #2
    1. Advertising

  3. santosh a écrit :
    > Hi,
    >
    > If I call free() with a uninitialised pointer, will the program
    > state become undefined, or will free() return harmlessly?


    Undefined behaviour. A serious bug. Don't do that. Never.

    > Incidentally, is there a way in Standard C to determine
    > weather a pointer points to a valid block of allocated
    > memory?


    Make it point to NULL by default or once free() has been performed. I
    recommend this construction :

    free(p), p = NULL;

    It makes it easy to test, and it happens that free (NULL) is defined and
    harmless.

    --
    A+

    Emmanuel Delahaye
    Emmanuel Delahaye, Dec 4, 2005
    #3
  4. In article <>,
    "santosh" <> wrote:

    > Hi,
    >
    > If I call free() with a uninitialised pointer, will the program
    > state become undefined, or will free() return harmlessly?


    First, it is undefined behavior, so _anything_ can happen. Especially,
    it might return harmlessly every time you do this while you are
    developping your program, and the first time it is used seriously it
    could crash the computer it is running on and cause considerable
    financial damage. Don't do this.

    What exactly happens depends on your implementation. The value of an
    uninitialised pointer variable might by great coincidence be the same as
    some pointer variable that was initialised by calling malloc. In that
    case, calling free () will free that pointer, with likely harmful
    consequences. That is not as unlikely as it seems, because an
    uninitialised variable might be kept in a register that happens to
    contain another completely unrelated variable of the calling function.
    Christian Bau, Dec 4, 2005
    #4
  5. santosh

    Daniel Rudy Guest

    At about the time of 12/4/2005 2:17 AM, santosh stated the following:

    > Hi,
    >
    > If I call free() with a uninitialised pointer, will the program
    > state become undefined, or will free() return harmlessly?


    Maybe, maybe not. The behavior is undefined. Undefined meaning that
    *ANYTHING* can happen, including your harddisk being reformatted (Which
    is admittidly an extream case).

    > Incidentally, is there a way in Standard C to determine
    > weather a pointer points to a valid block of allocated
    > memory?


    What I do is initialize all pointers to NULL when my program starts and
    on entries to functions right in the initialzation section. This is a
    good practice as it gives you a known starting point to go from.

    int ptest(int size)
    {
    void *p;

    p = NULL;
    p = malloc(size);
    if (p == NULL) return(-1);
    /* perform some action here */
    free(p);
    return(0);
    }

    In this case here, p can never have an unknown value. If the call to
    malloc fails, then malloc returns NULL, which can be tested for. Get
    into the habbit of setting all your pointers to NULL before and after
    you use them.

    > Thanks for your time.
    >


    --
    Daniel Rudy

    Email address has been base64 encoded to reduce spam
    Decode email address using b64decode or uudecode -m

    Why geeks like computers: look chat date touch grep make unzip
    strip view finger mount fcsk more fcsk yes spray umount sleep
    Daniel Rudy, Dec 4, 2005
    #5
  6. santosh

    Joe Wright Guest

    santosh wrote:
    > Hi,
    >
    > If I call free() with a uninitialised pointer, will the program
    > state become undefined, or will free() return harmlessly?
    >

    Undefined behavior. You can call free() once and only once on a pointer
    value returned by malloc & company. You can free(NULL) with no effect.

    > Incidentally, is there a way in Standard C to determine
    > weather a pointer points to a valid block of allocated
    > memory?
    >

    There is no way to determine by inspection the validity of any pointer
    value. The only pointer value that you are guaranteed to know something
    about is NULL and that it doesn't 'point' to anything.

    > Thanks for your time.
    >

    I've never had any real problem with the malloc()/free() stuff probably
    because of programming habit. I always write the beginning and end of
    functions at the same time. For example I begin a generic program with..

    #include <stdio.h>

    int main(void) {

    return 0;
    }

    ...and only then, fill it in with code. I tend to do the same with
    malloc/free and fopen/fclose. Properly written, whether to free or
    fclose is not the question, just do it.

    --
    Joe Wright
    "Everything should be made as simple as possible, but not simpler."
    --- Albert Einstein ---
    Joe Wright, Dec 4, 2005
    #6
  7. santosh

    Artie Gold Guest

    Emmanuel Delahaye wrote:
    > santosh a écrit :
    >
    >> Hi,
    >>
    >> If I call free() with a uninitialised pointer, will the program
    >> state become undefined, or will free() return harmlessly?

    >
    >
    > Undefined behaviour. A serious bug. Don't do that. Never.
    >
    >> Incidentally, is there a way in Standard C to determine
    >> weather a pointer points to a valid block of allocated
    >> memory?

    >
    >
    > Make it point to NULL by default or once free() has been performed. I
    > recommend this construction :
    >
    > free(p), p = NULL;
    >
    > It makes it easy to test, and it happens that free (NULL) is defined and
    > harmless.


    Unfortunately, there are cases where doing so will mask a logic error
    wherein otherwise a pointer would be free()-ed twice. So be careful.

    HTH,
    --ag

    >



    --
    Artie Gold -- Austin, Texas
    http://goldsays.blogspot.com
    http://www.cafepress.com/goldsays
    "If you have nothing to hide, you're not trying!"
    Artie Gold, Dec 4, 2005
    #7
  8. "santosh" <> writes:
    > If I call free() with a uninitialised pointer, will the program
    > state become undefined, or will free() return harmlessly?


    This is, of course undefined behavior, but not because of the call to
    free(). Any attempt to evaluate an uninitialized pointer variable
    invokes undefined behavior. For example:

    int *ptr; /* uninitialized */
    if (ptr == NULL) ...; /* undefined behavior */

    Realistically, the call to free() is more likely to cause something
    bad to happen than the evaluation of the argument.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
    We must do something. This is something. Therefore, we must do this.
    Keith Thompson, Dec 4, 2005
    #8
  9. santosh

    Jordan Abel Guest

    On 2005-12-04, Artie Gold <> wrote:
    > Emmanuel Delahaye wrote:
    >> santosh a écrit :
    >>
    >>> Hi,
    >>>
    >>> If I call free() with a uninitialised pointer, will the program
    >>> state become undefined, or will free() return harmlessly?

    >>
    >>
    >> Undefined behaviour. A serious bug. Don't do that. Never.
    >>
    >>> Incidentally, is there a way in Standard C to determine
    >>> weather a pointer points to a valid block of allocated
    >>> memory?

    >>
    >>
    >> Make it point to NULL by default or once free() has been performed. I
    >> recommend this construction :
    >>
    >> free(p), p = NULL;
    >>
    >> It makes it easy to test, and it happens that free (NULL) is defined and
    >> harmless.

    >
    > Unfortunately, there are cases where doing so will mask a logic error
    > wherein otherwise a pointer would be free()-ed twice. So be careful.


    it'll mask it or solve it? setting it to null guarantees that it won't
    be freed twice, so this is hardly a "mask" - it actually changes the
    logic to prevent the error
    Jordan Abel, Dec 4, 2005
    #9
  10. santosh

    santosh Guest

    Keith Thompson wrote:
    > "santosh" <> writes:
    > > If I call free() with a uninitialised pointer, will the program
    > > state become undefined, or will free() return harmlessly?

    >
    > This is, of course undefined behavior, but not because of the call to
    > free(). Any attempt to evaluate an uninitialized pointer variable
    > invokes undefined behavior. For example:
    >
    > int *ptr; /* uninitialized */
    > if (ptr == NULL) ...; /* undefined behavior */
    >
    > Realistically, the call to free() is more likely to cause something
    > bad to happen than the evaluation of the argument.


    Thank you all for your clear replies.

    To sum up, if I understand correctly, good programming implies
    that a pointer must either be NULL or must contain a known
    value, returned by malloc() and co.

    And if I do want to manipulate the lvalue, it is better to make a
    copy of the original pointer and deal with it. The lvalue must also
    be unchanged (i.e. the one that malloc() returned), when the pointer
    is passed to free().

    Are the above assumptions correct?

    Is even using the address of operator on an uninitialised pointer
    undefined?

    Thanks all.
    santosh, Dec 5, 2005
    #10
  11. santosh wrote:
    >
    > Hi,
    >
    > If I call free() with a uninitialised pointer, will the program
    > state become undefined, or will free() return harmlessly?


    Even if passing an invalid pointer to free() were permitted, imagine
    what would happen if this uninitialized pointer just happened to have
    the same value as a previously malloc'ed buffer. That alone should
    be enough to understand why this must be undefined behavior.

    > Incidentally, is there a way in Standard C to determine
    > weather a pointer points to a valid block of allocated
    > memory?


    No. I suppose you could put wrappers around malloc/calloc/recalloc/free
    which tracks all allocated buffers, and then supply a function to check
    if a pointer is in the list. This would, of course, only keep track of
    your memory allocations, and not anything done within any library calls.

    --
    +-------------------------+--------------------+-----------------------------+
    | Kenneth J. Brody | www.hvcomputer.com | |
    | kenbrody/at\spamcop.net | www.fptech.com | #include <std_disclaimer.h> |
    +-------------------------+--------------------+-----------------------------+
    Don't e-mail me at: <mailto:>
    Kenneth Brody, Dec 5, 2005
    #11
  12. santosh

    pete Guest

    santosh wrote:

    > Is even using the address of operator on an uninitialised pointer
    > undefined?


    No.
    The address of an object
    does not depend on the value of the object.
    Accessing the value of an uninitialised object,
    is where the problems come from.

    Likewise, the identifier of an uninitialised object
    can be a valid operand of the sizeof operator.

    --
    pete
    pete, Dec 5, 2005
    #12
  13. santosh

    Artie Gold Guest

    Jordan Abel wrote:
    > On 2005-12-04, Artie Gold <> wrote:
    >
    >>Emmanuel Delahaye wrote:
    >>
    >>>santosh a écrit :
    >>>
    >>>
    >>>>Hi,
    >>>>
    >>>>If I call free() with a uninitialised pointer, will the program
    >>>>state become undefined, or will free() return harmlessly?
    >>>
    >>>
    >>>Undefined behaviour. A serious bug. Don't do that. Never.
    >>>
    >>>
    >>>>Incidentally, is there a way in Standard C to determine
    >>>>weather a pointer points to a valid block of allocated
    >>>>memory?
    >>>
    >>>
    >>>Make it point to NULL by default or once free() has been performed. I
    >>>recommend this construction :
    >>>
    >>> free(p), p = NULL;
    >>>
    >>>It makes it easy to test, and it happens that free (NULL) is defined and
    >>>harmless.

    >>
    >>Unfortunately, there are cases where doing so will mask a logic error
    >>wherein otherwise a pointer would be free()-ed twice. So be careful.

    >
    >
    > it'll mask it or solve it? setting it to null guarantees that it won't
    > be freed twice, so this is hardly a "mask" - it actually changes the
    > logic to prevent the error


    Perhaps.

    It *will* avoid the UB -- but why, outside of very specific situations
    (where the programmer knows *exactly* what he/she is doing) would one
    free() the memory associated with a pointer more than once? And could it
    be a case of mistakenly free()-ing the *wrong* pointer, introducing a
    memory leak?

    Too often, such constructions are used more as a band-aid than as a well
    considered design decision (as it might be in the case of cleanup code
    after failed resource acquisition, for example).

    Just my .02.

    HTH,
    --ag
    --
    Artie Gold -- Austin, Texas
    http://goldsays.blogspot.com
    http://www.cafepress.com/goldsays
    "If you have nothing to hide, you're not trying!"
    Artie Gold, Dec 5, 2005
    #13
  14. "santosh" <> writes:
    > Keith Thompson wrote:
    >> "santosh" <> writes:
    >> > If I call free() with a uninitialised pointer, will the program
    >> > state become undefined, or will free() return harmlessly?

    >>
    >> This is, of course undefined behavior, but not because of the call to
    >> free(). Any attempt to evaluate an uninitialized pointer variable
    >> invokes undefined behavior. For example:
    >>
    >> int *ptr; /* uninitialized */
    >> if (ptr == NULL) ...; /* undefined behavior */
    >>
    >> Realistically, the call to free() is more likely to cause something
    >> bad to happen than the evaluation of the argument.

    >
    > Thank you all for your clear replies.
    >
    > To sum up, if I understand correctly, good programming implies
    > that a pointer must either be NULL or must contain a known
    > value, returned by malloc() and co.


    A pointer can also contain the address of a declared object. If
    you're not careful, this can cause similar problems if the object
    ceases to exist before the pointer does. For example:

    int *func(void)
    {
    int local_var;
    return &local_var;
    }

    local_var ceases to exist when func() returns, but the caller now has
    a pointer to this nonexistent object. If the caller attempts to use
    this pointer value, it will invoke undefined behavior.

    If you need to do this kind of thing, there are several workarounds.
    You can declare local_var as static (which means every call to func()
    will return the same address), or you can allocate the space with
    malloc() (which means it's up to the caller to free() it), or you can
    pass a pointer *into* the function and let the function assign a value
    to the pointed-to object (which means the caller has to know -- or
    guess -- how much space to allocate). This isn't likely to be an
    issue for a pointer to int, but it's common when you want your
    function to return an array, such as a string.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
    We must do something. This is something. Therefore, we must do this.
    Keith Thompson, Dec 5, 2005
    #14
    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. Andy Fish
    Replies:
    7
    Views:
    542
    David Carlisle
    Jan 10, 2005
  2. Gene Wirchenko
    Replies:
    22
    Views:
    721
    Jeffrey Schwab
    Dec 19, 2003
  3. Replies:
    2
    Views:
    275
    Rolf Magnus
    Feb 4, 2007
  4. Replies:
    2
    Views:
    285
    John Ratliff
    Feb 4, 2007
  5. BlueJ
    Replies:
    6
    Views:
    393
    Ben Bacarisse
    Oct 19, 2007
Loading...

Share This Page