malloc() vs buffer[]?

I wanted to know the difference between using malloc() to allocate data to a pointer and creating an array[].
I'm writing a program that gets data from the internet and stores a part of it. It reads a packet with the length of the data that is coming next, then it malloc()'s space for it and gets it. It happens that, somewhere I may need to do something like storageArea = &packet[x]. This means I can't free(packet) anymore. Would it be better if instead of using malloc() and not freeing the pointer, I created a buffer and maybe afford losing some memory?

it really depends on what you're doing with the data afterwards. If you'll need the information later, you'll want to malloc it so that it will stick around after local variables go out of scope. Also, malloc is useful when you don't know how much memory you'll need at compile-time.

Quote:

---

It happens that, somewhere I may need to do something like storageArea = &packet[x]. This means I can't free(packet) anymore.

---

why not? I think you can. Am I missing something here? You'll have to free it eventually.

Local function variables are destroyed some time around function the time that the function ends. There is no need for you to free() them. When you malloc() something, that block of memory stays beyond the function's life. You can do more with such a dynamically allocated buffer imo.

Also of note, memory is allocated from different places if it's a local buffer vs a dynamic one.

Packet is the pointer that was set using malloc(), and storageArea is another pointer, where the data will be stored. If I do "storageArea = &packet[x]", "free(packet)" and then do something with storageArea the program will segfault, because I freed the whole packet memory, and storageArea now points the area freed.
the packet pointer is passed as argument to the function that will handle it.

Don't free() it if you don't want to lose it.

Yep, but would it be more efficient than using a buffer? Estimate a length and memcpy the contents of the packet to the storage area and free(packet)?

Perhaps a stupid question, but why not just copy it to the storage area to begin with?

Because it needs to be processed first... A part of it will go to one storage area, then another part will go to another and so on. Then I may need to use storageArea = &packet[x] storageArea2 = &packet[y] storageArea3 = packet[z] and so on. The example I gave above was just an example of what I need to do with the data... By now the program works without having to free the pointer since I'm going to use it later on, but I was wondering if it wasn't better to copy stuff and freeing it, instead of pointing to it, in order to avoid memory leaks.

This:

Code:

---

struct example
{
unsigned char *storageArea;
unsigned char *storageArea2;
unsigned char storageArea3;
};

unsigned char *packet = malloc(length);
getpacketfromnet(packet);
storageArea = &packet[3];
storageArea2 = &packet[7];
storageArea3 = packet[22];

---

or this:

Code:

---

struct example
{
unsigned char storageArea[300]; //300 is an expected length
unsigned char storageArea2[200]; //200 is an expected length
unsigned char storageArea3;
};

unsigned char *packet = malloc(length);
getpacketfromnet(packet);
strcpy(storageArea, &packet[3]);
strcpy(storageArea2, &packet[7]);
storageArea3 = packet[22];
free(packet);

---

is safer / best?

the result is logically different - so firstly - decide what is CORRECT version.

You can use strcpy only on NULL-terminated strings
You loose the pointer you need to free later in the first version

So both versions contain errors

Assuming they are NULL-terminated strings. If you didn't get what I meant, use memcpy with a a random size then, I didn't want to come up with another variable. This is an _example_ code, it doesn't have to be perfect, it's just to show you the problem. I would understand if you said that if I was asking wether to use memcpy or strcpy.
I didn't get what you said about the first version

Quote:

---

This is an _example_ code

---

Ok - here is the _example_ answer - it depends.

I'm just asking if it's better to copy data and free the pointer or if it's ok to point to it without freeing the pointer. Feel free to ignore the code if you think it contain errors, as long as you get the general idea.

Ok - ignoring the code - It depends. Sometimes copying is better, sometimes - just storing the pointer to the extern buffer. Satisfied?

When is it better doing each thing?

Personally, I'd go with option 2 until such time that I could prove option 1 had much better (and needed) performance. If you choose option 1, make sure packet is a member of the struct.

Copying a few bytes (whether by memcpy or strcpy) is insignificant to the time it took to transmit those bytes over the net, or what other work you have planned later on.

> unsigned char storageArea[300]; //300 is an expected length
Or you could have a char pointer (as per case 1) then allocate the exact space you need, then copy the data.

Simply put, option 1 is a program logic and maintenance nightmare. You have three apparently independent members of the struct all pointing to the same memory area. It becomes very hard to keep track of who is responsible for freeing the memory, and when. It becomes even harder to find it out from the code after forgetting it. (Or the code is then maintained by someone else.)

So as Salem said, go with option 2 unless you really, really, REALLY need the performance of option 1.

Ty! That was the answer I needed :) Thx a lot

Krones