libmemcache 1.0.1

[John McCaskey]

On Wed, 2004-12-08 at 16:06 -0800, Sean Chittenden wrote:
> > It seems I didn't test my patch for long values enough ;)
> 
> Heh.  I need to develop a good set of regression tests for this, which 
> I haven't done yet.  My current tests (and production) only use 
> libmemcache(3) with smaller values.  I suppose a good way to identify 
> problems would be to set GET_INIT_BUF_SIZE to something insanely small 
> like 32 and watch it work from there.
> 

I'll include an update that can help with this to your main.c with my
next patch.

> > Each time the read() command was reading more and more (first pass 
> > 1024,
> > second 2048, ...) where as each time it should read 1024.  This was
> > caused by my not updating the mc->cur to mc->read_cur in one of the
> > calculations.
> 
> I need to reread this chunk of code.

Yeah, I think apart from my attempts to quickly patch it some more
changes can clean it up a bit.  I'm going to go through it and try to do
so.

> 
> > See attached second patch which is just two quick changes of mc->cur ->
> > mc->read_cur.  This patch is against 1.0.2 as I haven't had a chance to
> > take a look at the 1.1.0rc1 yet today, but I suspect you can convert it
> > over very easily.
> 
> Yup.  I've committed your patch to 1.1.  Just be warned, the changes to 
> the code are extensive in the sense that patches against 1.0.X will 
> have to be manually applied to the 1.1 code.
> 
> > Sorry for the mistake!
> 
> Don't apologize, it was my bug to begin with.  I should be the one with 
> the pointy hat.  I've been meaning to do an audit of mcm_get_line() 
> anyway: I'll try and get to that tonight or tomorrow morning.  -sc
> 
Great, I'll try to do a full audit of it tonight as well and submit a
patch.  Feel free to then reject it if you come up with a cleaner
solution on your own!

-- 
John A. McCaskey
Software Development Engineer
Klir Technologies, Inc.
johnm at klir.com
206.902.2027