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.