From: Lars-Erik Bjørk Date: June 12 2009 8:13am Subject: Re: Potential bug? List-Archive: http://lists.mysql.com/falcon/763 Message-Id: MIME-Version: 1.0 Content-Type: text/plain; delsp=yes; format=flowed; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Yes, I will do that. It does not fix my current problems, though, but I am pretty sure tha= t =20 this 'would be' / 'is the cause of' some bug, somewhere :) /Lars On Jun 10, 2009, at 6:33 PM, Christopher Powers wrote: > Kevin Lewis wrote: >> Lars-Erik, >> >> Good catch. This function is in used three places within =20 >> IndexRootPage::indexMerge and nowhere else. This might be your bu= g =20 >> that causes badly sorted indexes. >> >> Kevin > I agree. There are three ::setKey() methods. Can you group them = =20 > together in the header and cpp file? >> >> Lars-Erik Bj=F8rk wrote: >>> Hi all! >>> >>> I came across the following funny snippet of code: >>> >>> void IndexKey::setKey(int offset, int length, const UCHAR *data) >>> { >>> memcpy(key + offset, data, length); >>> length =3D offset + length; >>> } >>> >>> I assume the writer intended to write 'keyLength =3D offset + len= gth'? >>> >>> Unless someone has any objections, I will push a patch for this = =20 >>> (without a review :) ) >>> and hope some existing issues disappear :) >>> >>> /Lars-Erik >>> >> >