Re: svn_kstring_t

Some notes:

"string" (for constant counted string) and "stringbuf" (for modifiable
counted string) are more intuitive names than "kstring" and "string".
I'll assume your terminology for the rest of these comments, though.

Avoid macros which know about the internal structure of a string
(either kind). They complicate the ABI.

Creating a kstring will still require a pool, to allocate the
structure, even though it doesn't require a pool to allocate the
actual data.

We could--I'm not sure whether I like this idea or not--pass around
actual kstring structures and not merely pointers to them. It's quite
portable given that we're assuming ANSI C. This would finesse the
issue of requiring a pool, and would be very much like passing around
separate <data,length> arguments without the pain. But it has some
minor down sides, like you can't use NULL any more.

It's also possible that we use constant, counted strings rarely enough
that we should just pass around the data and length as separate
parameters; there might not be enough pain to really warrant creating
an abstraction.

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