do 2.0 pools have free and realloc now?
'cause otherwise an arbitrary string class like this is encouraging people
to bleed memory left and right.
for a historical reference search for O(n^2) in the archives, you'll find
many cases where arbitrary string allocation caused apache to have some
pretty egregious DoS attacks. search bugtraq too while you're at it.
-dean
On Fri, 23 Feb 2001, Greg Stein wrote:
> On Fri, Feb 23, 2001 at 04:45:52PM -0800, [EMAIL PROTECTED] wrote:
> > On Fri, 23 Feb 2001, Jim Jagielski wrote:
> >
> > > Greg Stein wrote:
> > > >
> > > > In the future, if we want to optimize away strlen() calls, then we should
> > > > introduced a "counted string" type. Subversion has one, along with a bunch
> > > > of support functions, which is APR pool-aware. We could snarf those if we
> > > > chose. [and place them into APRUTIL]
> > > >
> > >
> > > Hows the performance? Does it provide too much overheard for
> > > it to be a generic solution? But I'm +1 for this addition.
>
> Performance? Not a problem. They're visible structures:
>
> /* The svn_string_t data type. Pretty much what you expected. */
> typedef struct svn_string_t
> {
> char *data; /* pointer to the bytestring */
> apr_size_t len; /* length of bytestring */
> apr_size_t blocksize; /* total size of buffer allocated */
> /* pool from which this string was originally allocated, and is not
> necessarily specific to this string. This is used only for
> allocating more memory from when the string needs to grow. */
> apr_pool_t *pool;
> } svn_string_t;
>
> We pass around "svn_string_t *" values. Accessing the data is simply
> str->data. The string is guaranteed to be null-terminated, which simplifies
> interop with OS functions. It is also counted, so things like memcpy() can
> be used. (the null-term is not counted in "len")
>
> Since it is counted, it is also useful for binary data.
>
> > I'm +1 for it too. I would put it directly into APR though. Two string
> > types, counted and regular. But that's just an opinion.
>
> Actually, a good one. I said APRUTIL simply because it's totally portable.
> But APR itself would want to use this datatype, I'm sure.
>
>
> That is two +1 votes, and a +1 from me. I've attached the header for review.
>
> Cheers,
> -g
>
> --
> Greg Stein, http://www.lyra.org/
>
