Karl Fogel wrote:
>Branko Čibej <email@example.com> writes:
>>Oh, well. I dislike creating stuff in the user's home in lieu of
>>documentation ... -0
>Mrm. Okay. Separate discussion, but I'll point out that we've done
>basically the same thing in the FS, for a long time now.
>>>The benefit is not having to clutter other code with stringbufs. APIs
>>>that demand stringbufs when null-terminated strings would do just as
>>>well place a burden on their callers. That's why we've been getting
>>>rid of stringbufs all over the place lately.
>>Um. They weren't stringbufs, they were string_t's. There's a
>>difference -- no allocations, for one thing.
>And that's the only thing. :-) My comment about the burden on the
>callers still applies.
>>>Is there some reason we need the length of the string? It's not
>>>binary data, after all.
>>The *user* of the code may need it, to avoid strlens. I thought that's
>>what svn_string_t was for.
>>Sure, kill the stringbufs where they're not needed, but string_t's are
>>useful, imho, and quite as easy to use as plain pointers.
>The purposes of svn_string_t are also to give counted-length binary
>data. Config data is always null-terminated. Anyway, this change is
>entirely consistent with the API decisions/changes we've been making
>for months now, losing counted-length strings in favor of C strings.
>When do the callers need to do strlen(), realistically? Mostly they
>do string comparisons and pattern matching. If they do need the
>length, they can take strlen(), but so far it hardly ever happens.
>I do not find svn_string_t as easy to use as plain pointers. I have
>to set them up, and then end up dereferencing the data field anyway
>for all those functions that take "const char *". Ugh. (I mean, I
>changed the API because it *was* hampering me, not because I thought
>it might do so at some future date.)
I seem to remember that string_t was created to make swig bindings
easier to write. If that's not the case any more, then I really mind
Brane Čibej <brane_at_xbc.nu> http://www.xbc.nu/brane/
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Wed Mar 20 20:54:27 2002