Grow object from memory pool (realloc)

Legato Application Framework
1

Hiya,

Is there an equivalent of realloc() to grow the size of an object’s allocated space from a memory pool?

Or do I need to allocate a second object of a larger size and copy it across?

In fact, how do you define the size of an object to allocate on the fly?

Use Case:

Variable length text string is being received across a file descriptor.

In ‘conventional C’, I would initially allocate a block of data (say 512 bytes) and keep count how long my string is. When I reach the end of the block, I realloc() the block to a bigger size and continue receiving the string.

Is this possible with memory pools? Or do I just fix a giant size (8k?20k?100k?) and hope that I never run out?

ciao, Dave

2

The size of the elements in the memory pool is fixed, but the number of elements in the memory pool can be expanded by using le_mem_ForceAlloc. Memory pools work nicely when you are allocating fixed size items, but they are quite wasteful if you are using them as you are to accept a variable length string. Is there an upper and lower bound on the size of the string? If there is and the upper and lower bound are somewhat close together, then I think a memory pool may still make sense.

Is there a requirement that the string data is stored contiguously when you receive it? Obviously that’s the case if you want to use standard string functions on it. If you do need it to be contiguous, then there are two options that I can think of. One is to just use malloc/realloc as you originally mentioned. The other is to create a memory pool of a struct like this:

struct StringFragment
{
    char data[64];
    le_sls_Link_t link;
};

And then create a linked list of the fragments as they are coming in and then do one malloc at the end once the entire string has arrived and copy the data from the fragments into the string and remove the fragments. This approach seems like it’s probably going to be more complicated to implement and slow to execute though, so I would go with the malloc/realloc approach.