Realloc() and Free()

[Lamblion]

I have the following in my code...

void* bScratchVar=realloc( bWriteBuffer, dwTotal + 1 );
			bWriteBuffer=(BYTE*)bScratchVar;
			bScratchVar=NULL;

Do I need to free bScratchVar before I set it to NULL, or is it okay the way it is?

IOW, should I do this...

bWriteBuffer=(BYTE*)bScratchVar;
          free( bScratchVar );
          bScratchVar=NULL;

Or can I leave the free() out of it altogether, which is what I've been doing with absolutely no problems whatsoever?

I should also mention that all of this is inside a loop, which is why I'm reallocating memory.

I just want to make sure I'm doing it the right way.

[firedraco]

You MUST free it before you change the pointer, otherwise you have a memory leak.

which is what I've been doing with absolutely no problems whatsoever?

You probably won't run into any issues unless you start leaking very large amount of memory (like >MBs), but if you have lots of your program running or it runs for a long time, it can (and will) add up.

[Lamblion]

Thanks very much. I only allow one instance of my program, so that's one reason I have had no problems, plus the memory amount is not huge, but nevertheless, I want to do it right, and of course avoid this issue in future programs, so once again, thanks for letting me know.

[webJose]

Since malloc(), calloc(), realloc(), and free() are C functions and I haven't used them for a long time, I can't be sure but I believe that realloc() frees the original buffer if its new size cannot be accommodated in its current position, so I think it is safe to assign the new pointer to bWriteBuffer without freeing the old pointer value.

Visual Studio allows peeking the RAM (probably other IDE's too). Peek the RAM pointed to by bWriteBuffer before the call to realloc() in debug mode. Usually, the debug CRT will change the value of the memory to signal its deletion. If you see this happening, then you are OK without freeing the memory yourself.

[Lamblion]

webJose, I think you are right. I just put the free( bScratchVar) in there before I set it to NULL and it caused an exception and crash every time.

I then ran it through the debugger, plus I did a MessageBox() debug as well -:), and it showed that bScratchVar was empty without using the free().

It's a bit confusing, but I think I'll go with the old adage, if it ain't broke, don't fix it.

[firedraco]

Ah, I misunderstood, and I see what you are doing now. Since you have another pointer to the data, you DON'T want to free it, otherwise the other pointer you had will now be pointing at what you just freed (which was probably why you got a segfault).

[Lamblion]

Okay, that makes sense. That's what I thought was happening after I ran it through the debugger.

Except I don't understand why both variables don't now contain the data. IOW, I have declared...

BYTE* bWriteBuffer;
void* bScratchVar;

So as you can see from my first example in my first post above, I have reallocated the data from bWriteBuffer into bScratchVar. I then assign bWriteBugger back to bScratchVar with the old plus the new data, so why don't both variaboles contain the data?

Or is the data on the heap and in one spot and the variables are just pointing to it?

I hope I'm making myself clear.

[webJose]

The correct way of doing it (if I remember correctly) is this:

void *bScratchVar = realloc(bWriteBuffer, total + 1);
if (bScratchVar) bWriteBuffer = (BYTE*)bScratchVar;

This should account for the cases where NULL is returned because you are out of memory.

So, if you get a non-null pointer, then just use it and be happy that you won't leak memory through the old pointer as realloc() has taken care of it (so long it was allocated with malloc()).

[Lamblion]

I first read the data into bWriteBuffer, then I reallocate memory into bScratchVar, as shown in my first post.

So the question is, where is the data IMMEDIATELY after I reassign the old and new data in bScratchVar back to bWriteBuffer?

IOW, do BOTH variables contain data before I set bScratchVar to NULL, or is there just one set of data on the heap and both variables are pointing to that one set of data?

[webJose]

Realloc() will automatically move the data to the potentially new location, and a pointer to the new location is returned and save into bScratchVar. This means that there is no guarantee that, after realloc(), the bWriteBuffer is a valid buffer. It may be, but it may have been freed by realloc(). Remember that allocations have to fit in a single block of memory. If the current block has no room to accommodate the new amount, then a new block is used and the data contained in the old block is copied to the new location automatically.

[Lamblion]

Yeah, but what I'm curious about is if bScratchVar and bWriteBuffer contain the SAME data BEFORE I set bScratchVar to NULL.

IOW, in my first post above, when I do this...

void* bScratchVar=realloc( bWriteBuffer, dwTotal + 1 );
	   bWriteBuffer=(BYTE*)bScratchVar;

Now, BEFORE I set bScratchVar to NULL, do BOTH bScratchVar AND bWriteBuffer contain the same data?

[webJose]

Important choice of words there. I must say: Both bScratchVar and bWriteBuffer POINT to the same data. You don't have the data duplicated anywhere after realloc() returns.

[Lamblion]

That's what I was hoping. And that clears it up for me.