> On Sat, 7 Jul 2001 [EMAIL PROTECTED] wrote: > > > +1, personally I would prefer to have the length returned in the parameter > > list. > > I was leaning that way as well for consistency with apr_pstrcat(). > > > Or, we could do something I have been considering since I started > > APR. We could create an apr_string_t. This would be a simple type, with > > just a char * and a length. The goal would be to use an apr_string_t > > whenever we already have a length. I would love to find a way to pack the > > length into a simple C string, but since that isn't really possible, I > > think creating a new string type might make sense. > > Oh yeah, I'd forgotten about that. I recall the discussions on that front > from a while back... didn't Greg mention that he had such a beast in use > somewhere (Subversion maybe)? Anyhow, it's a great idea and I'm all for > it, but it will take a lot of work and some pretty widespread changes to > put it to use, so an apr_pstrlencat() seems like a reasonable quick > fix/stopgap measure to me.
I think you misunderstand my meaning. We should do both. I don't believe that forcing every APR app to use apr_string_t's is a good idea. They are a useful thing to have, because they remove a lot of performance problems at times, but so are NULL-terminated strings that have no length. We should create the apr_string_t, and use it only where it makes sense. One place that it makes sense, is to create apr_pstrlencat, but it returns a pointer to an apr_string_t. It would still accept two char *'s. In the future, we may create an apr_pstringlencat that accepts two apr_string_t's, but we don't need to do that immediately. Ryan _____________________________________________________________________________ Ryan Bloom [EMAIL PROTECTED] Covalent Technologies [EMAIL PROTECTED] -----------------------------------------------------------------------------
