httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From dean gaudet <dgaudet-list-new-ht...@arctic.org>
Subject Re: counted strings (was: Re: SGI Patch 10xpatch-2.0a6-5 - eliminate use of sprintf() to format inet_ntoa conversions)
Date Sun, 25 Feb 2001 23:32:53 GMT
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, rbb@covalent.net 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/
>


Mime
View raw message