0

I'm redefining memory functions in C and I wonder if this idea could work as implementation for the free() function:

    typedef struct _mem_dictionary
    {
        void *addr;
        size_t size;
    } mem_dictionary;

    mem_dictionary *dictionary = NULL; //array of memory dictionaries
    int dictionary_ct = 0;         //dictionary struct counter

void *malloc(size_t size)
   {
    void *return_ptr = (void *) sbrk(size); 

    if (dictionary == NULL) 
        dictionary = (void *) sbrk(1024 * sizeof(mem_dictionary));  




    dictionary[dictionary_ct].addr = return_ptr; 
    dictionary[dictionary_ct].size = size;      
    dictionary_ct++;                 
    printf("malloc(): %p assigned memory\n",return_ptr); 
    return return_ptr;               

    }

    void free(void *ptr)
    {


    size_t i;
    int flag = 0;

     for(i = 0; i < dictionary_ct ; i++){

        if(dictionary[i].addr == ptr){
            dictionary[i].addr=NULL;
            dictionary[i].size = 0;
            flag = 1;
            break;
            }
        }

        if(!flag){
            printf("Remember to free!\n");
        }


    }

Thanks in advance!

g0d1anier
  • 48
  • 6
  • 1
    What implementations of `free` are possible depends entirely on your implementation of `malloc`. Strictly speaking, redefinition of either produces undefined behavior, but redefinition of some of the `malloc`-family functions without defining all of them is much worse and sure to crash. I think you need to clarify what you're doing and what you're trying to achieve... – R.. GitHub STOP HELPING ICE Jan 12 '11 at 03:59
  • 2
    The implementation of `free` is intimately related to the implementation of `malloc`. Where's `malloc`? As it stands you're not returning anything to the free store with your `free`, so you're causing all clients to leak tons of memory. – Billy ONeal Jan 12 '11 at 03:59
  • Redefining functions like `malloc` and `free` is a tedious job. I've done tons of adventurous things before, but I don't think I've ever gone this far. – zneak Jan 12 '11 at 04:07
  • True, sorry I forgot to add the malloc function already implemented. Edited. – g0d1anier Jan 12 '11 at 04:13
  • 1
    Oh, man! You are so wrong about `sbrk()` ... – Nikolai Fetissov Jan 12 '11 at 04:19

2 Answers2

2

No, it will not. The address you are "freeing" is effectively lost after such a call. How would you ever know that the particular chunk of memory is again available for allocation?

There has been a lot of research in this area, here is some overview - Fast Memory Allocation in Dr. Dobbs.

Edit 0:

You are wrong about sbrk(2) - it's not a "better malloc" and you cannot use it as such. That system call modifies end of process data segment.

Nikolai Fetissov
  • 82,306
  • 11
  • 110
  • 171
0

Few things:

  1. Where do you allocate the memory for the dictionary?
  2. How do you allocate the memory that dictionary->addr is pointing at? Without having the code for your malloc it is not visible if your free would work.
  3. Unless in your malloc function you're going through each and every memory address available to the process to check if it is not used by your dictionary, merely the assignment dictionary[i].addr=NULL would not "free" the memory, and definitely not keep it for reuse.

BTW, the printf function in your version of free would print Remember to free! when the user calls free on a pointer that is supposedly not allocated, right? Then why "remember to free"?

Edit:

So with that malloc function, no, your free does not free the memory. First of all, you're losing the address of the memory, so every time you call this malloc you're actually pushing the process break a little further, and never reuse freed memory locations. One way to solve this is to somehow keep track of locations that you have "freed" so that next time that malloc is called, you can check if you have enough available memory already allocated to the process, and then reuse those locations. Also, remember that sbrk is a wrapper around brk which is an expensive system call, you should optimize your malloc so that a big chunk of memory is requested from OS using sbrk and then just keep track of which part you're using, and which part is available.

Peyman
  • 447
  • 3
  • 7