apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <...@covalent.net>
Subject Re: apr_pstrcat()
Date Sun, 08 Jul 2001 05:54:18 GMT

> On Sat, 7 Jul 2001 rbb@covalent.net 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 Bloom                        	rbb@apache.org
Covalent Technologies			rbb@covalent.net

View raw message