Re: Advice on how to return a list of values

Remo D. wrote:
> Hi! I'm writing a function that returns an array of (at maximum) 64
> pointers to char. I have thought of three possibility:
> 
> - The caller p***** a pointer to a previously allocated array of 64
> pointers. Similarly to sprintf(), the caller is entirely responsible for
> handling the memory. The drawback is that my function will have to rely
> on the correctness of such pointer to work properly.
> 
> - My function allocates the array and returns it. This is similar to
> strdup(). Here I will have to rely on the caller function to properly
> free the array, which is something I'm not very comfortable with.
> 
> - I'll have a  "static char *ret[64]" in my function and will return
> ret. I've not been able to think of a library function that behaves this
> way, so I guess it's not reccomended. The good is that I'm free from
> allocation/freeing problem.   The bad is that the return values will be
> overwritten at each call; if the user wants to keep the return values
> for subsequent use he has to copy and store them somewhere.  Another
> drawback is that it consumes memory even if the function will never be
> called.
> 
> In my specific case, I was leaning toward the third option but I'd like
> to hear your opinion on pitfalls, things that I've missed or alternative
> approaches that could work better.
> 
The first would be my choice.

There are standard C (time functions for example) and many POISX
networking functions return a pointer to shared internal data.  The
biggest drawback with this is it can cause chaos in threaded
applications.  So they (POSIX) also provide another version which accept
the data to be written as a parameter.

-- 
Ian Collins.