Right now, errors are kept in a subpool of the topmost pool created by
svn_pool_create(). This is complicated and of little value, since
error memory generally needs to be managed explicitly. It would
simplify our code base noticeably if errors were kept in a subpool of
the global pool (what you get if you do svn_pool_create(NULL)), so
that svn_error_create() does not need to take a pool parameter.
Functions would then no longer need to take a pool parameter just
because they can return errors. (When removing a pool parameter from
a function in the public API, we do want to consider whether a future
implementation might need to allocate memory, but there are no doubt a
lot of cases where it should be safe.)
Some subtleties:
* Allocate each error in a separate pool, so that it can be cleared
separately. svn_error_clear_all() is a dangerous interface, since
another error might be in the process of being handled.
* When allocating an error with a child, use the child's pool, so
chained errors all live in the same pool.
* This would be a good time to clean up the __FILE__ and __LINE__
handling by collecting that information in all circumstances and
passing the file and line as extra arguments to the true name of the
svn_error_create() functions. (Some concern has been voiced that if
the compiler doesn't fold string constants, this could blow up the
size of the object files, but I doubt any modern compiler doesn't fold
string constants, or that the increased size would be terribly
noticeable if they didn't.)
* svncpp and the SWIG bindings will be affected by interface
changes, of course.
Task
Major