Again, what is bizarre about this I/F is that it returns a pointer. But sometimes that pointer is to internal static memory and sometimes that pointer is to the memory that you just gave the I/F! In the first case, you had better use that info right away or make your own copy of it for later use - this idea is also non-thread-safe and non-reentrant. To fix that problem, I would dynamically allocate memory for the result and return a pointer to that. If we go with option 2, then the user is responsible for allocating and passing a pointer to enough memory for the result. The problem here is that the sub doesn't know how big of a buffer you have given it. And in general the guy who produces the result is in a much better position to estimate the size of the result than the caller. It is unusual to say the least for option 1 and option 2 to both be available depending upon the calling parms.

Back to Perl. When was the last time you saw an I/F like this? If I pass the sub a reference for the output, say \$output, I would expect that result goes into my $output and the sub perhaps returns some success or failure code. More likely is that the sub returns an array, a scalar or a reference to an array and perhaps undef on failure. I can't think of a Perl I/F where I am required to pass a reference to an output structure in all cases and undef when I don't want the sub to use that reference for output when instead I want to look for the output as the return value. There is usually one way to give the input and one way to get the output. subs that transform data via a reference to an input. structure are quite common.

Back to C. Memory allocation in C is a major issue and the source of many, many bugs. Ambiguity about who is allocating memory and who is responsible for it after allocation is "a big deal".

I don't know why you replied to my point about C with your thoughts about Perl interfaces, but thanks. In Perl there are many options, including returning a list of results (with a result status as first entry), or a hash-ref with a "status" member.

In C, dealing with memory management is important. One can document who is responsible for deallocating data whose pointer is returned. Another option, used in recent PDL, is to return a pdl_error struct that has as members:

• an integer for the error type (including none)
• a char * pointer for any error text
• a flag saying whether that char * would need freeing after use (so if the string needed sprintf-ing and therefore first malloc-ing, that works without memory leaks)
Easy, and seems to have no problems so far (except thread-safe realloc for error-accumulation in Windows, but that was straightforward given previous work in PDL on that).

Parenthetically, the idea behind that is so that all PDL functions can return these thingies on error, instead of using a C-level exception mechanism. That means the PDL C library can start being used in other C-language applications, or have an interface for other dynamic languages.