We've never been very focused on those kinds of "leaks", on the assumption that the parent or child pool will be cleared at some point, thus free'ing the handle.
Cheers, -g On Sat, Sep 18, 2010 at 13:47, Daniel Shahaf <d...@daniel.shahaf.name> wrote: > http://colabti.org/irclogger/irclogger_log/svn-dev?date=2010-09-07#l40 > describes a scenario where a file handle would be leaked due to a pool > not being freed; specifically, > > parent(pool) calls child(pool); > child(pool) allocates handle from POOL; > child(pool) triggers an SVN_ERR(); > handle remains allocated. > > Are there any other cases where this would be a problem? > > > Should we adopt a strategy of > > #define SVN_ERR_CLEAR(expr, scratch_pool) > do { > svn_error_clear(scratch_pool); > SVN_ERR(expr); > } while(0) > > at least in some functions taking a scratch_pool argument? > > > (We could have this only for maintainer-mode builds, and > #define SVN_ERR_CLEAR(expr, pool) SVN_ERR(expr) > for normal builds.) > >
