Re: svn_kstring_t

On Wed, Jun 06, 2001 at 05:01:24PM -0400, Greg Hudson wrote:
> Some notes:
>
> "string" (for constant counted string) and "stringbuf" (for modifiable
> counted string) are more intuitive names than "kstring" and "string".

Agreed. Unfortunately, I'm not sure if we could pull off this name change
since svn_string_t means something quite different. (I think the problem
mostly from the human angle of changing the semantics of the "svn_string_t"
which is in their brains)

I'm +1 on your suggested naming. Thoughts from others?

[ hmm. maybe we do a two-step: add svn_stringbuf_t first and do a mass
  rename. then we add svn_string_t. then start changing the usage. ]

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

Hmm. Not sure that I see this. How can a macro affect the ABI? Are you
thinking in terms of making it harder in the future to change the structure
/ layout of the svn_string_t datatype? I don't see how avoiding macros can
help, given that the structure(s) are public.

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

Nope. We don't need pools for the structure:

    svn_kstring_t ks = { "hello", sizeof("hello") - 1 };

    function(&ks);

In fact, we can even put these into global const variables now (because
there is no pool field):

    static const svn_kstring_t ks = ...

Now... if the svn_kstring_t structure is *opaque*, then yes: we would need a
pool. But I'm not sure that I see the benefit for making it opaque.

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

I'm not that these follow since we can easily put the structures on the
stack...

Note that if a function is going to store an svn_kstring_t, it needs to
dup() it just like it would need to copy an svn_string_t (to ensure that the
passed-in value has the correct lifetime). That dup will be allocated from a
pool.

Cheers,
-g

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