[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: CVS update: MODIFIED: libsvn_subr ...

From: Greg Stein <gstein_at_lyra.org>
Date: 2001-06-14 00:31:33 CEST

On Tue, Jun 12, 2001 at 08:48:58PM -0000, sussman@tigris.org wrote:
> User: sussman
> Date: 01/06/12 13:48:58
> Modified: subversion/libsvn_subr svn_error.c
> Log:
> * svn_error.c (initialize_svn_error_descriptions): new func - build a
> hash table that maps svn errorcodes to english descriptions.
> (svn_strerror): take a pool instead of stringbuf. pass
> this pool to initialize_svn_error_descriptions() the first time this
> routine is called, and then cache the hash in a static variable
> thereafter. use the hash for lookups.
> (svn_error_strings[]): removed, now part of hash initialization.

This isn't going to work well.

If the first person to call svn_strerror() passes a subpool, then future
callers will get garbaged if that pool has gone away. It is fixable by using
a cleanup so the hash can be rebuilt for another caller.

However, this is also overengineered. We don't need a hash table since this
function won't be called often. A simple linear scan over a table is
sufficient. That would allow constant data to be used for the whole table.

Also... the disconnect between the enumeration in the header and the
definitions in the .c file will cause skew. No matter how much we may
document, somebody will insert an error at the top/bottom/middle and won't
see any comments we leave behind.

And lastly, it would be nice to just call svn_strerror() and have it grab
the APR error for us, if it falls in the APR range. No need for callers to
know everything about the ranges.

I've got a design for rectifying all of this, and can implement tonite. I
explained the evil macros to Karl if you can't wait to see the code :-)

[ the gist is to have a header that can create both the enumeration and the
  error string table, depending on how it is included ]


Greg Stein, http://www.lyra.org/
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:36:31 2006

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.