Question: In C, it is possible for functions to return pointers to memory that that function dynamically-allocated and require the calling code to free it. It's also common to require that the calling code supplies a buffer to a second function, which then sets the contents of that buffer. For example:

```
struct mystruct {
   int a;
   char *b;
};

struct mystruct *get_a_struct(int a, char*b)
{
    struct mystruct *m = malloc(sizeof(struct mystruct));
    m->a = a;
    m->b = b;

    return m;
}

int init_a_struct(int a, char*b, struct mystruct *s)
{
    int success = 0;
    if (a < 10) {
        success = 1;
        s->a = a;
        s->b = b;
    }

    return success;
}

```

Is one or the other method preferable? I can think of arguments for both: for the get\_a\_struct method the calling code is simplified because it only needs to *free()* the returned struct; for the init\_a\_struct method there is a very low likelihood that the calling code will fail to *free()* dynamically-allocated memory since the calling code itself probably allocated it.

Answer: 
It depends on the specific situation but in general supplying the allocated buffer seems to be preferable. 

As mentioned by Jim, DLLs can cause problems if called function allocates memory. That would be the case if you decide to distribute the code as a Dll and get\_a\_struct is exported to/is visible by the users of the DLL. Then the users have to figure out, hopefully from documentation, if they should free the memory using free, delete or other OS specific function. Furthermore, even if they use the correct function to free the memory they might be using a different version of the C/C++ runtime. This can lead to bugs that are rather hard to find. Check [this](http://blogs.msdn.com/b/oldnewthing/archive/2006/09/15/755966.aspx) Raymond Chen post or search for "memory allocation dll boundaries". The typical solution is export from the DLL your own free function. So you will have the pair: get\_a\_struct/release\_a\_struct. 

In the other hand, sometimes only the called function knows the amount of memory that needs to be allocated. In this case it makes more sense for the called function to do the allocation. If that is not possible, say because of the DLL boundary issue, a typical albeit ugly solution is to provide a mechanism to find this information. For example in Windows the [GetCurrentDirectory](http://msdn.microsoft.com/en-us/library/windows/desktop/aa364934.aspx) function will return the required buffer size if you pass 0 and NULL as its parameters.
The "pass an pointer in is preferred", unless it's absolutely required that every object is a "new object allocated from the heap" for some logistical reason - e.g. it's going to be put into a linked list as a node, and the linked-list handler will eventually destroy the elements by calling free - or some other situation where "all things created from here will go to `free` later on). 

Note that "not calling `malloc`" is always the preferred solution if possible. Not only does calling `malloc` take some time, it also means that some place, you will have to call `free` on the allocated memory, and every allocated object takes several bytes (typically 12-40 bytes) of "overhead" - so allocating space for small objects is definitely wasteful.