Derrell, > That's kinda yucky. (No, that's really yucky.) Is there some reason that > you > wouldn't want the caller to just free the error string, or better yet, for > the > error string to always just be allocated on the ldb context so that it gets > freed automagically? With everything so clean in ldb, this seems like a real > oversight.
yes, there are very good reasons for doing it the way it is done! 1) callers mostly don't look for the error string, so if we allocate at the time the error happens and the caller doesn't call ldb_errstring() then we have leaked. So the backend has to free it in that case anyway. 2) when the backend gets an allocation error, the last thing you want to do to report the error is another allocation! 3) always allocating on the ldb context would give us a massive memory leak for long lived connections. Notice that ldb_errstring() retruns a "const char *". The "const" is a hint that the caller does not free (note that talloc_free() takes a non-const, just like free()). Having an error function that returns a string that the caller does not free is the normal approach to this problem in lots and lots of APIs. Have a look at calls like ldap_err2string() for an example. Cheers, Tridge
