views:

98

answers:

5

Inside my template function I have the following code:

TypeName myFunction()
{

    TypeName result;
    void * storage = malloc( sizeof( TypeName ) );

    /*Magic code that stores a value in the space pointed to by storage*/

    result = *(TypeName *)storage;

    free( storage );
    return result;
}

This causes an "HEAP CORRUPTION DETECTED" error.If I don't call the free() function, the error doesn't occur, but I am afraid that I am creating a memory leak.what would be the proper way to return the value of "storage" and then deallocate the memory?

+2  A: 

don't call it like this:

TypeName result;
void * storage = malloc( 4 );

you should call it

TypeName result;
void * storage = malloc( sizeof(TypeName) );

anyway code looks strange :)

Andrey
It's not actual code, it's a small scaled model of what is causing my problem:) You're completely right , there shouldn't be magic "4"s lingering around any database:))
Emil D
+3  A: 

You don't need to allocate storage, You could probably pass your result variable into a function that does your magic stuff. Something like this.

void magic(void *buffer)
{
  // magic stuff 
}

TypeName foo()
{
   TypeName result;
   magic(&result);
   return result;
}

Or of course you could have your TypeName structure set up as bit-fields or whatever your magic code manipulate...

Liz Albin
+1 for reading into the question, digging past the mechanics, and suggesting the simplest solution.
Adam Liss
Yes , normally that would be the intelligent thing to do...but as it often happens, i cannot do this in my case:S Some of the magic code involves assembly and stack manipulation, so I really cannot make another function call in there:S:S
Emil D
A: 

Why did you malloc with 4 bytes and yet casted to the type name of TypeName? That definitely looks odd!

The other answers are hinting you what it is...!

Hope this helps, Best regards, Tom.

tommieb75
+1  A: 

I think your confusion lies in this line:

 void * storage = malloc( 4 );

It looks like you're trying to allocate space for a 4-byte pointer, but that's not what you need to do. Let's break the line into two steps:

void * storage;          // This allocates 4 bytes for a variable of type "pointer to void"
storage = malloc( 4 );   // This allocates 4 _more_ bytes and sets "storage" to their address.

I'm assuming that the "magic" code copies data from a variable of type Typename to the memory that was allocated for storage with this effect:

memcpy(storage, data_from_a_Typename_variable, sizeof(Typename));

So if sizeof(Typename) is larger than the 4 bytes that were allocated to storage you'll see the heap-corruption error.

As the other answers indicate, what you need to do is allocate enough space for a Typename variable, like this:

void * storage = malloc(sizeof(Typename));

But, as Liz Albin suggested, you've already allocated space for a Typename in result so it's simpler to pass &result or (void *) &result to the magic function.

Adam Liss
+1  A: 

What about:

TypeName myFunction() {
    TypeName result;
    void* storage = &result;

    /*Magic code that stores a value in the space pointed to by storage*/

    return result;
}

Here, all your variables will be stored on the stack so you shouldn't encounter heap-related problems (depending on what exactly your "magic" code does).

Is there a reason why you have your storage array separate from result? If the results will simply be copied into result, it would make more sense (IMHO) to only use one object (and either keep a void* pointer to it or type-cast &result as needed).

If there is a reason to use a separate storage and result, you will probably get better milage using TypeName storage = new TypeName and delete instead of malloc(4) and free.

bta
I'll try that, frankly I separated result and storage out of habit: every time I write a new function, the first lines I put in are type result; return result;so the IDE stops complaining:)EDIT: Works perfectly:) Thanks a bunch, I guess this show how little real-life experience i have with references :)))
Emil D
Yeah, let's replace heap corruption with stack corruption for the latter is harder to notice...
sbk
Do elaborate, what problem do you think this action would introduce?I honestly don't see the harm that can potentially be done to the stack, so if you have something in mind, it would help me a lot:))
Emil D