You are viewing a plain text version of this content. The canonical link for it is here.
Posted to c-dev@xerces.apache.org by Jeff Lewis <jd...@xactware.com> on 2000/05/16 16:54:18 UTC

RE: getElementByID() - Patch

Here is a patch for <BUG_1>, all I did was increment currentHash just before
the continue otherwise we get stuck in an infinite loop: 
AttrImpl *NodeIDMap::find(const DOMString &id)
{
//
// Get the hashcode for the supplied string.
//
unsigned int initalHash = XMLString::hashN(id.rawBuffer(), id.length(),
fSize-1);
initalHash++;
unsigned int currentHash = initalHash; 
//
// Loop looking for a slot pointing to an attr with this id.
//
while (true)
{
AttrImpl *tableSlot = fTable[currentHash];
if (tableSlot == 0)
{
// There is no matching entry in the table
return 0;
} 
if (tableSlot == (AttrImpl *)-1)
{
// This slot contains an entry for a removed attribute.
// We need to keep looking - the one we are after could
// still show up later on. 
currentHash++;
continue;
} 
if (tableSlot->getValue().equals(id))
return tableSlot; 
currentHash += initalHash; // rehash
}
return 0; // Never gets here, but keeps some compilers happy.
};



Re: getElementByID() - Patch

Posted by Andy Heninger <an...@jtcsv.com>.
RE: getElementByID() - Patch <BUG_1>The fix is even easier.  Just drop out
the check for deleted (-1)
slots from the lookup loop altogether.  They aren't zero, and they
aren't what we are searching for, so the right thing happens.

  - Andy

----- Original Message -----
From: Andy Heninger
To: xerces-c-dev@xml.apache.org
Sent: Tuesday, May 16, 2000 9:27 AM
Subject: Re: getElementByID() - Patch <BUG_1>


Hi Jeff,

   The fix for this problem wants to be
     currentHash += initialHash;

   rather than
      currentHash++;


Re: getElementByID() - Patch

Posted by Andy Heninger <an...@jtcsv.com>.
RE: getElementByID() - Patch <BUG_1>Hi Jeff,

   The fix for this problem wants to be
     currentHash += initialHash;

   rather than 
      currentHash++;

   The idea is to have the sequence of slots that are visited on lookup exactly track the sequence that was followed during the add, when searching for an empty slot to use.

All of these problems that you are finding are a textbook example of why I shouldn't have done this at all, but found some suitable, already debugged code to use.  

And I wouldn't be at all surprised to find something wrong with the grow-the-table code, which I haven't checked yet either.

  -- Andy


  ----- Original Message ----- 
  From: Jeff Lewis 
  To: 'xerces-c-dev@xml.apache.org' 
  Sent: Tuesday, May 16, 2000 7:54 AM
  Subject: RE: getElementByID() - Patch <BUG_1>


  Here is a patch for <BUG_1>, all I did was increment currentHash just before the continue otherwise we get stuck in an infinite loop: 

  AttrImpl *NodeIDMap::find(const DOMString &id)
  {
  //
  // Get the hashcode for the supplied string.
  //
  unsigned int initalHash = XMLString::hashN(id.rawBuffer(), id.length(), fSize-1);
  initalHash++;
  unsigned int currentHash = initalHash; 
  //
  // Loop looking for a slot pointing to an attr with this id.
  //
  while (true)
  {
  AttrImpl *tableSlot = fTable[currentHash];
  if (tableSlot == 0)
  {
  // There is no matching entry in the table
  return 0;
  } 
  if (tableSlot == (AttrImpl *)-1)
  {
  // This slot contains an entry for a removed attribute.
  // We need to keep looking - the one we are after could
  // still show up later on. 
  currentHash++;
  continue;
  } 
  if (tableSlot->getValue().equals(id))
  return tableSlot; 
  currentHash += initalHash; // rehash
  }
  return 0; // Never gets here, but keeps some compilers happy.
  };