Re: [PATCH] add pool pointer to svn_string_t

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
thing.

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:

       Measure First�!

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.
>
> -K

-- 
Brane �ibej
  home:   <brane_at_xbc.nu>            http://www.xbc.nu/brane/
   ACM:   <brane_at_acm.org>           http://www.acm.org/