More questions on realloc

Discussion in 'C Programming' started by James S. Singleton, Nov 29, 2005.

  1. Thanks to everybody who provided an answer to my previous question on
    this. I am trying to grasp the nitty-gritty details of this, and I am
    having difficulties understanding some of the issues involved.

    According to the man page (and I quote)

    realloc(void *ptr, size_t size) changes the size of the memory block
    pointed to by ptr to size bytes. The contents will be unchanged to the
    minimum of the old and new sizes; newly allocated memory will be
    uninitialized.

    Let's assume the following sequence (my apologies for the sloppiness of
    my language in what follows; I am taking for granted that experienced C
    insiders will have no difficulty cutting through it):

    p = malloc(size1) ;

    /* Code to copy some stuff to the memory area pointed to by p */

    q = realloc(p, size2) ;

    For simplicity, I will assume that q != p. With this, my understanding is
    that realloc will copy the contents of p to q, to the appropriate length,
    and will then free p.

    My question is, how does realloc know that p points to a memory region
    size1 bytes in length? Or, to put it differently, can realloc be
    implemented with malloc, and no other memory management call?
     
    James S. Singleton, Nov 29, 2005
    #1
    1. Advertising

  2. On Tue, 29 Nov 2005 17:01:17 GMT, in comp.lang.c , "James S.
    Singleton" <> wrote:

    > My question is, how does realloc know that p points to a memory region
    >size1 bytes in length?


    By magic.

    Seriously, this is an implementation detail that the end user doesn't
    actually need to know. Under the hood it might be doing all sorts of
    things (a lookup table of malloced blocks and their sizes, storing the
    size in memor just before the malloced block, etc etc. But you don't
    need to know - it just works.

    >Or, to put it differently, can realloc be
    >implemented with malloc, and no other memory management call?


    You'd need memcpy and free. How else can you copy the memory from the
    old to the new pointers, and then free the old one?

    --
    Mark McIntyre
    CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
    CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>

    ----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
    http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
    ----= East and West-Coast Server Farms - Total Privacy via Encryption =----
     
    Mark McIntyre, Nov 29, 2005
    #2
    1. Advertising

  3. James S. Singleton

    Eric Sosman Guest

    James S. Singleton wrote On 11/29/05 12:01,:
    > Thanks to everybody who provided an answer to my previous question on
    > this. I am trying to grasp the nitty-gritty details of this, and I am
    > having difficulties understanding some of the issues involved.
    >
    > According to the man page (and I quote)
    >
    > realloc(void *ptr, size_t size) changes the size of the memory block
    > pointed to by ptr to size bytes. The contents will be unchanged to the
    > minimum of the old and new sizes; newly allocated memory will be
    > uninitialized.
    >
    > Let's assume the following sequence (my apologies for the sloppiness of
    > my language in what follows; I am taking for granted that experienced C
    > insiders will have no difficulty cutting through it):
    >
    > p = malloc(size1) ;
    >
    > /* Code to copy some stuff to the memory area pointed to by p */
    >
    > q = realloc(p, size2) ;
    >
    > For simplicity, I will assume that q != p. With this, my understanding is
    > that realloc will copy the contents of p to q, to the appropriate length,
    > and will then free p.
    >
    > My question is, how does realloc know that p points to a memory region
    > size1 bytes in length? Or, to put it differently, can realloc be
    > implemented with malloc, and no other memory management call?


    The memory-management functions keep track of the
    sizes of allocated and available blocks of memory. The
    details of how this is done differ from one implementation
    to another. One frequently-used method is to allocate a
    little bit more memory than is requested, plant some
    housekeeping data at the beginnning, and return a pointer
    to the tail end. Later, free() or realloc() can look "just
    before" the pointer they're given to find the housekeeping
    data again.

    ... but that's just one way; others exist. From the
    programmer's perspective, it's all "implementation magic,"
    just like the machinery behind, say, fopen(). You don't
    (usually) care how the spell is cast, just that the magic
    happens.

    --
     
    Eric Sosman, Nov 29, 2005
    #3
  4. Mark McIntyre wrote:
    > On Tue, 29 Nov 2005 17:01:17 GMT, in comp.lang.c , "James S.
    > Singleton" <> wrote:
    >
    >
    >> My question is, how does realloc know that p points to a memory region
    >>size1 bytes in length?

    >
    >
    > [snip]
    >
    >>Or, to put it differently, can realloc be
    >>implemented with malloc, and no other memory management call?

    >
    >
    > You'd need memcpy and free. How else can you copy the memory from the
    > old to the new pointers, and then free the old one?
    >

    But realloc doesn't always have to reallocate memory; if you malloc,
    say, 10 bytes, you may well actually get 32 (or 1024) bytes. Your C
    library knows how much but you don't, so calling realloc() is often a
    win over malloc(), memcpy() and free().

    Robert
     
    Robert Harris, Nov 29, 2005
    #4
  5. On Tue, 29 Nov 2005 17:27:48 GMT, in comp.lang.c , Robert Harris
    <> wrote:

    >Mark McIntyre wrote:
    >> On Tue, 29 Nov 2005 17:01:17 GMT, in comp.lang.c , "James S.
    >> Singleton" <> wrote:
    >>
    >>>Or, to put it differently, can realloc be
    >>>implemented with malloc, and no other memory management call?

    >>
    >> You'd need memcpy and free. How else can you copy the memory from the
    >> old to the new pointers, and then free the old one?
    >>

    >But realloc doesn't always have to reallocate memory; if you malloc,
    >say, 10 bytes, you may well actually get 32 (or 1024) bytes.


    This is sometimes true, but not relevant to the OP since
    a) you don't know if your compiler can do this and
    b) you don't know if it did, in any specific case and
    c) it may in any events not be able to, in any specific case.

    Whatever, realloc can under the hood operate however it likes,
    provided it behaves *as if* it had done a new *alloc, copy and free.
    --
    Mark McIntyre
    CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
    CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>

    ----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
    http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
    ----= East and West-Coast Server Farms - Total Privacy via Encryption =----
     
    Mark McIntyre, Nov 29, 2005
    #5
  6. "James S. Singleton" <> writes:

    > Let's assume the following sequence (my apologies for the sloppiness of
    > my language in what follows; I am taking for granted that experienced C
    > insiders will have no difficulty cutting through it):
    >
    > p = malloc(size1) ;
    >
    > /* Code to copy some stuff to the memory area pointed to by p */
    >
    > q = realloc(p, size2) ;
    >
    > For simplicity, I will assume that q != p. With this, my understanding is
    > that realloc will copy the contents of p to q, to the appropriate length,
    > and will then free p.
    >
    > My question is, how does realloc know that p points to a memory region
    > size1 bytes in length? Or, to put it differently, can realloc be
    > implemented with malloc, and no other memory management call?


    As others already have said, it's an implementation detail. My guess is that the
    most common scheme is to have the size of a memory block stored immediatly before
    the block in question. This is also the reason why writing beyond the end of an
    allocated block can have so strange effects, crashing a program much later in
    a totally different context, making it difficult to debug.

    K & R has a section describing a typical memory allocator. I recommend you to
    read that.

    Realloc could be implemented in terms of malloc, free, and memcpy, but you
    would lose the possibility to extend an existing memory block without the
    need of copy in the case that there are enough free memory adjacent to the
    current block. Note that it is trivial to implement both malloc and free in
    terms of realloc:

    void* malloc(size_t sz) { return realloc(NULL, sz); }
    void free(void* ptr) { realloc(ptr, 0); }

    /Niklas Norrthon
     
    Niklas Norrthon, Nov 30, 2005
    #6
    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. Mr T
    Replies:
    0
    Views:
    615
  2. Eitan Michaelson

    Impossible Leak realloc

    Eitan Michaelson, Jun 27, 2003, in forum: C++
    Replies:
    11
    Views:
    1,230
  3. Michael
    Replies:
    4
    Views:
    472
    Matt Hammond
    Jun 26, 2006
  4. James S. Singleton

    More questions on realloc - Thanks

    James S. Singleton, Nov 29, 2005, in forum: C Programming
    Replies:
    10
    Views:
    637
    S.Tobias
    Dec 1, 2005
  5. Robert Klemme

    With a Ruby Yell: more, more more!

    Robert Klemme, Sep 28, 2005, in forum: Ruby
    Replies:
    5
    Views:
    241
    Jeff Wood
    Sep 29, 2005
Loading...

Share This Page