Just my ´┐Ż 2E-2 ...
We can safely replace a svn_string_t with a char pointer iff the
argument is a `const char *' and we know the function expects
a nul-terminated string. In any other case it's begging for trouble.
Astracting the fundamental brokenness of C strings is IMNSHO a good
I'd advise to leave well enough alone. If passing around svn_string_t's
turns out to be a performance problem -- something we definitely won't
care about until at least 1.0 -- then sure enough, find the hot spots
and fix them, but:
Karl Fogel wrote:
> I actually still prefer to use svn_string_t even when carrying plain
> old c-string data, because:
> Subversion strings provide that one extra level of indirection -- by
> wrapping the data pointer, we get resizes that work in the happy way.
> Also, now strings store their pools, which may help readability and
> prevent allocation-lifetime bugs.
> Were we to use (char *) instead, and use the apr string functions
> everywhere, then things like svn_path_*() wouldn't be able to
> side-effect the string's data. So we'd probably end up with
> return-by-reference arguments where we currently don't need them, or
> else values would have to get passed up call chains in order to
> satisfy someone's original assignment statement.
> Even post-M1, I'd like to keep using svn_string_t as we have been,
> unless a majority of developers feel strongly about switching.
home: <brane_at_xbc.nu> http://www.xbc.nu/brane/
ACM: <brane_at_acm.org> http://www.acm.org/
Received on Sat Oct 21 14:36:11 2006